On Tue, Feb 22, 2011 at 5:22 AM, supplier <supplier@icido.de> wrote:
3 > // Connecting to the existing shared memory 4 > SharedMemoryRiiConnector shmem("Some Name");
FYI: Such RAII wrappers are often called ScopedXyz, like boost::scoped_ptr for example.
6 > // Do some stuff here, for example calling a function creating objects 7 > TypeR* instance = createObjectInSharedMemory(); 8 > 9 > // Call a member function of TypeR 10 > instance->doSomething(); 11 > [...] 12 > } 13 > 14 > TypeR* classB::createObjectInSharedMemory() 15 > { 16 > // Connect to the shared memory again to allow working in this 17 > SharedMemoryRiiConnector shmem("Some Name"); 18 > 19 > // Create an object in the shared memory using the interface of the 20 > // RII object, which uses the Boost.Interprocess functions to handle allocation 21 > TypeR* instance = shmem.createObject<TypeR>("Example Object"); 22 > return instance; 23 > }
The app I work on uses SHM and on Windows I noticed that when you attach several time to the same SHM segment in different parts of the same process, you don't necessarily get back the same pointer. We don't use Boost for the SHM handling and I don't know what's in your SharedMemoryRiiConnector, so we may be in a different situation, but if SharedMemoryRiiConnector re-opens the SHM, the address you get on line 17 might be different than the address you get on line 4, and the first address is only valid in the scope of classB::createObjectInSharedMemory, since the RAII wrapper likely closes its SHM segment on line 23. It's only a guess, but as it fits your symptoms I'm throwing it out there. Good luck, --DD