home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 15830 < prev    next >
Encoding:
Text File  |  1992-11-05  |  3.4 KB  |  106 lines
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!spool.mu.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!agate!doc.ic.ac.uk!uknet!mcsun!sunic!seunet!enea!ermes!eny
  2. From: eny@ermes.enea.se (Erik Nykvist)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Linked Lists in Shared Memory:
  5. Message-ID: <1992Nov5.090303.17760@ermes.enea.se>
  6. Date: 5 Nov 92 09:03:03 GMT
  7. References: <1992Nov2.195623.20262@lsil.com>
  8. Organization: Project ERMES, Teli Telecom Sweden
  9. Lines: 95
  10.  
  11. ameesh@lsil.com (Ameesh Desai) writes:
  12. > In article 8463@BofA.com, karl@BofA.COM (Karl Nicholas) writes:
  13. > >
  14. > >    Greetings Netters:
  15. > >
  16. > >    I would like to build a linked list in 
  17. > >shared or global memory. 
  18. > 
  19. > 
  20. > 
  21. > *** BEWARE of the virtual table pointers ***
  22. > 
  23. > When sharing data, what you must take care of is that nothing in the shared memory
  24. > points to a local processes address space. You can easily take care of this by
  25. > allocating everything from shared memory using say an overloaded new operator.
  26. > 
  27. > What you do not control is the virtual table pointers generated by cfront
  28. > that will point into the local address space of the process that allocates the
  29. > object (calling the ctor).
  30. > 
  31. > Simple Solution:
  32. > 
  33. > Do not use virtual functions in objects that you want to share !
  34. >     This is very limiting. You can use some form of indirection to create
  35. >     your own version of virtual function implementation, but this will not 
  36. >     be as clean as the one provided by C++.
  37. > 
  38. > There could be other solutions such as, allow only one process to map the 
  39. > pages and fix the vtable pointers for that process. This could be slow !
  40. > 
  41. > Ask some ODBMS vendors ... they seemed to have solved this problem in some
  42. > manner. I suspect that they do not actually 'share' the *same* pages accross
  43. > processes. They must map them to different swap pages and fix the vtable ptrs.
  44. > 
  45. > Ameesh
  46. > 
  47. > ---
  48. > ______________________________     o__            
  49. > | _   /|     Ameesh Desai     \    ,>/_                              
  50. > | \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
  51. > | =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
  52. > |____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097 
  53.  
  54. I have used a technique based on the new-operator with placement-syntax.
  55. If we have objects that can only be accessed by one process at the time it
  56. is possible to adjust the this-pointer using this operator.
  57.  
  58. As long as the constructor used doesn't mutate the data members the affect of
  59. using this operator is only adjustment of the vtbl-pointer.
  60.  
  61. Example:
  62.  
  63. enum eIN_SHARED_MEMORY { IN_SHARED_MEMORY };
  64.  
  65. // I am not sure if you can overload based on enum:s yet
  66. // Assume there is a base class that provides a locking 
  67. // mechanism.
  68. class Shared : public Shared_Object
  69. {
  70. public:
  71.   Shared(eIN_SHARED_MEMORY) {}
  72.   Shared() : i(12) {}
  73.   virtual void foo();
  74.   void set(int);
  75. private:
  76.   int i;
  77. };
  78.  
  79. void
  80. Shared::foo()
  81. {
  82.    return i;
  83. }
  84.  
  85. // We also use the placement syntax to allocate the shared object.
  86. =========
  87. PROCESS 1
  88. =========
  89. {
  90.     Shared* sp = new (shared_mem) Shared;
  91.     Lock lock(*sp);
  92.     // Adjust vtbl
  93.     new (shared_mem) Shared(IN_SHARED_MEMORY);
  94.     sp->set(12);
  95.     cout << sp->foo() ,, endl;
  96.     ....
  97. }
  98.  
  99. I wonder if this technique can be of any practical use. I am not sure because
  100. my expericene in this field is only limited.
  101.  
  102. There are many problems to solve, inheritance, ... etc
  103.  
  104. Erik Nyquist, ENEA DATA AB,     erny@enea.se
  105.                 eny@ermes.enea.se
  106.