[Bug libstdc++/21251] Placement into shared memory
--- 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
--- 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
[Bug libstdc++/21251] Placement into shared memory
-- 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
--- 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
--- 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
--- 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 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
--- 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
