[Bug c++/21251] New: Placement into shared memory

[Bug c++/21251] New: Placement into shared memory

[mronell at alumni dot upenn dot edu]

I  would like  to use  placement to  instantiate a  C++ object  into a
shared memory  segment and access  that object from a  second process.
When I test with an integer, the integer is accessible from the second
process.  But when I instantiate a C++ class object, it seems a memory
pointer, which is local within the first process, is placed in memory.
The place object is fully  accessible and usable in the first process.
I am guessing that the pointer points to the class definition within a
table local  to that first process.  Unfortunately,  that table, which
does not  seem to  exist at  the same address  in the  second process,
causes the second process to Seg  fault when it attempts to access the
object instantiated in shared memory.

What  is the  current  correct approach  to  instantiating objects  in
shared memory so that multiple processes can access the C++ objects?

-- 
           Summary: Placement into shared memory
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mronell at alumni dot upenn dot edu
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug c++/21251] Placement into shared memory

[mronell at alumni dot upenn dot edu]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|                            |i686-pc-linux-gnu
   GCC host triplet|                            |i686-pc-linux-gnu
 GCC target triplet|                            |i686-pc-linux-gnu
           Keywords|                            |wrong-code
            Version|unknown                     |3.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug c++/21251] Placement into shared memory

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-27 14:03 -------
Are you talking about the vtable being at two different locations, well there is no way since the struct is 
a non-POD which means it cannot do many things with.

If you want to share data, try with a POD instead.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
  GCC build triplet|i686-pc-linux-gnu           |
   GCC host triplet|i686-pc-linux-gnu           |
 GCC target triplet|i686-pc-linux-gnu           |
           Keywords|wrong-code                  |
         Resolution|                            |INVALID
            Version|3.4.3                       |unknown


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug c++/21251] Placement into shared memory

[mronell at alumni dot upenn dot edu]

------- Additional Comments From mronell at alumni dot upenn dot edu  2005-04-27 14:56 -------
I believe that the pointer points to a component within the vtable, 
but I do not want to jump to that conclusion.  When the object is
instantiated in shared memory, the first element seems to be a pointer
to something, probably the vtable, followed by what appears to be
object field values.

What does 'POD' stand for?  I am not great with acronyms.

Thank you.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug c++/21251] Placement into shared memory

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-27 15:01 -------
(POD ("Plain Old Data") is a technical term, defined in the standard, basically
something you can copy bit by bit, via memcpy)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug c++/21251] Placement into shared memory

[mronell at alumni dot upenn dot edu]

------- Additional Comments From mronell at alumni dot upenn dot edu  2005-04-28 01:32 -------
"Plain Old Data" unfortunately is not a good solution in my case.  I maintain
http://allocator.sourceforge.net which provides an open-source shared memory
allocator for the C++ Standard Template Library.  This allocator has worked
with earlier versions of gcc/g++, but it depends on being able to instantiate
objects successfully in shared memory allowing multiple processes to access
the same objects.  Localized vtable pointers would cause problems.

I have a new version of the allocator revised based on Knuth's Dynamic Memory
Storage algorithm from his Vol. 1.  Its similar to Doug Lea's malloc.

However, as before, my approach depends on being able to place and share C++
objects through shared memory.  Its that still possible? 

Am I missing some esoteric compiler flags?  Is this a bug or future feature request?

Thanks for your suggestions and input.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug libstdc++/21251] Placement into shared memory

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-28 01:44 -------
(In reply to comment #4)
> However, as before, my approach depends on being able to place and share C++
> objects through shared memory.  Its that still possible? 
> 
> Am I missing some esoteric compiler flags?  Is this a bug or future feature request?

No it is not possible.  Now if you convince the standards committe that this is really should be possible, 
then we will implement their recommendation but as of now, there is no way sorry.

>  This allocator has worked
> with earlier versions of gcc/g++, but it depends on being able to instantiate
> objects successfully in shared memory allowing multiple processes to access
> the same objects.

What versions?  I really doubt that it worked at all as vtable implementation has only changed on what 
is the layout of the vtable.

> "Plain Old Data" unfortunately is not a good solution in my case.  I maintain
> http://allocator.sourceforge.net which provides an open-source shared memory
> allocator for the C++ Standard Template Library.

Hmm, there allocators have specific requirements in C++. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
          Component|c++                         |libstdc++
         Resolution|                            |INVALID
            Version|unknown                     |3.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug libstdc++/21251] Placement into shared memory

[mronell at alumni dot upenn dot edu]

------- Additional Comments From mronell at alumni dot upenn dot edu  2005-05-02 16:49 -------
Apologies for my persistence, but  the following is still not clear to
me.  Given the last reply to this concern, I now understand:

   1. Placement into  shared memory is  not possible.  If  processes 1
      instantiates  objects  into  shared memory,  these  instantiated
      objects can not necessarily be accessed by process 2 because the
      vtable  class definitions will  not necessarily  be at  the same
      address in both processes.

So given  the assumption  above, is a  share memory allocator  for the
Standard  Template  Library  (STL)  containers  still  possible?   For
example,  let process  1 create  a vector<T,A>  my_vect where  A  is a
working shared  memory allocator  and T is  a valid  class definition.
The allocator A,  is assumed to correctly allocate  and recycle memory
from an validly  open shared memory segment.  After  process 1 defines
and populates my_vect with objects  of type T, let process 2 similarly
define a  vector using  its own  allocator A, defined  the same  as in
process 1.  The allocator, A,  in process 2 accesses the shared memory
segment in exactly the same way as in process 1.  The address space of
the shared memory segment is  mapped to the same virtual address space
in  both  processes.   If  the   objects  in  the  vector  which  were
instantiated  by process  1 all  point  to process  1's vtable,  won't
process  2 have  trouble accessing  the objects  created by  process 1
because  process  2 may  again  have  its  vtable classes  defined  at
different memory addresses?  How can process 2 make use of the objects
mapped into shared memory by  process 1?  Is a shared memory allocator
for the STL  possible given that object placement  in shared memory is
not possible?  What is the difference between the two concepts and why
does one work (shared memory  allocator) and one not work (placement)?
Can you  point me to a reference  which explains this concept  as I do
not understand.

I am probably missing something obvious.

Thank you,

Marc



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug libstdc++/21251] Placement into shared memory

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-05-02 18:10 -------
Marc, we are talking about two completely different issues. Indeed, it's
*perfectly* possible using a shared-memory allocator with the STL containers.
In fact, we are in the process of providing an allocator of that type as part
of our library, just wait a bit more. OK?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug libstdc++/21251] Placement into shared memory

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2005-05-10 18:32 -------

Adding 16612. 

This is a higher-priority enhancement request. We need a shared_memory
allocator, a lot of people want it, it would be cool and useful, etc.

The one in 16612 is not going to work. We don't and can't get assignment, and
the design is weak. 

-benjamin

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |16612


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug libstdc++/21251] Placement into shared memory

[bkoz at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug libstdc++/21251] Placement into shared memory

[pcarlini at suse dot de]

------- Comment #10 from pcarlini at suse dot de  2005-11-15 22:38 -------
To be sure we don't confuse two issues here (see also my #7), all the
containers
are already able to use shared memory allocators such as libmm:

  http://www.ossp.org/pkg/lib/mm/

(via a very lightweight wrapper). This is even true for basic_string if config
with --fully-dynamic-string, and certainly for ext/vstring (or basic_string in
v7-branch). Another thing is the first issue in this PR, i.e., using a
placement
new in shared memory, the last comment #9 if I understand well, things like
that. Maybe it would be better separate the two issues in separate PRs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug libstdc++/21251] Placement into shared memory

[et at ihear dot com]

------- Comment #9 from et at ihear dot com  2005-11-15 22:10 -------
This cripples virtual inheritance for fine-grain parallel processing. There
should at least be a compiler option for process-independent referencing,
because admittedly, this would slow down dereferencing. Or maybe a operator new
placement variant that specifies process-independent referencing. I can see
that either way, it would cause major ripple effects. Maybe that's why I don't
see any action on this item since May.

I am making this comment because I think it is a very important enhancement to
make as soon as possible, as processors go multi-core. I have also read that
the other signicifant c++ compiler uses process independent referencing.


-- 

et at ihear dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |et at ihear dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251