Bug 21251 - Placement into shared memory
Summary: Placement into shared memory
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.3
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-27 13:56 UTC by Marc Ronell
Modified: 2014-02-16 13:16 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Ronell 2005-04-27 13:56:04 UTC
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?
Comment 1 Andrew Pinski 2005-04-27 14:03:35 UTC
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.
Comment 2 Marc Ronell 2005-04-27 14:56:32 UTC
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.
Comment 3 Paolo Carlini 2005-04-27 15:01:49 UTC
(POD ("Plain Old Data") is a technical term, defined in the standard, basically
something you can copy bit by bit, via memcpy)
Comment 4 Marc Ronell 2005-04-28 01:32:57 UTC
"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.
Comment 5 Andrew Pinski 2005-04-28 01:44:14 UTC
(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++. 
Comment 6 Marc Ronell 2005-05-02 16:49:45 UTC
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

Comment 7 Paolo Carlini 2005-05-02 18:10:27 UTC
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?
Comment 8 Benjamin Kosnik 2005-05-10 18:32:35 UTC
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
Comment 9 Elaine Tsiang 2005-11-15 22:10:52 UTC
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.

Comment 10 Paolo Carlini 2005-11-15 22:38:42 UTC
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.
Comment 11 Marc Ronell 2005-11-16 02:01:13 UTC
If placement using new into shared memory allows process independent memory referencing, other  software tools (including allocators) can be developed.  

This request asks, can placement into shared memory be provided for 
independent processes?

Please remove the added dependence on 16612.  Maybe the component should
also be switched to c++?
Comment 12 Andrew Pinski 2005-11-16 02:07:07 UTC
This almost need to go to the standards committee for how to deal with this (and maybe instead the IA64 ABI mailing list as we just follow that ABI for C++).
Comment 13 Andrew Pinski 2006-04-22 20:44:50 UTC
There is no way non PODs will ever work with shared memory.  This is why they are called non-PODs and they never should be shared outside of the program.  In fact non-PODs cannot be passed via var-args or even look at offsetof for each of the fields.
Comment 14 Marc Ronell 2006-05-03 02:39:41 UTC
It seems to me an approach using thunks, or pass by name, or a similar 
approach should work.  Each process can evaluate the object in shared
memory with reference to the local virtual table to gain access to the
specified C++ type and its methods.

I imagine when it worked before under gcc, it was because the gcc compiler
had a better implementation of thunks.

I would like to see if Stroustrup could suggest a better solution?  Have
you tried contacting some of that caliber in compiler design for 
suggestions?  

There may also be computer engineering hardware approaches which could
be faster than software.  Something like a set of base/limit registers
sitting on the memory bus which are swapped in and out during process
context switches.

Thanks

Marc
Comment 15 Andrew Pinski 2006-05-03 04:03:19 UTC
(In reply to comment #14)
> I would like to see if Stroustrup could suggest a better solution?  Have
> you tried contacting some of that caliber in compiler design for 
> suggestions?  

Why don't you write to comp.lang.c++?

This is not the correct form to ask about the C++ standard or any new features with C++.

Also thunks have nothing to do with the problem here. 
Comment 16 Jackie Rosen 2014-02-16 13:16:52 UTC Comment hidden (spam)