Questions about Boost shared memory

3
votes

I'm trying to put up a simple but portable way to use shared memory. Boost::interprocess seemed like a good place to start, but I ran into some problems/concerns.

  1. Can I somehow query existence of shm segment, preferably using boost API? I could always try to create it using create_only and catch an exception, but that's bad design, I don't want stack unwinding in the "good" path.
  2. Can I truncate the segment even while other processes are attached? (provided I'll handle the synchronization, ofcourse) I suppose all the other processes would have to re-map, would they also have to re-attach?
  3. Boost doc says that on windows the portable shared_memory_object isn't actually shared memory per se, but rather a memory-mapped file. Did I understand that correctly? This means I'll have to use specialized code on windows, which I was trying to avoid. Makes me question Boost's fitness for my purpose, is there an alternative? Instead of fighting with boost, I might as well write platform-specific code myself - in your opinion, would that be worth the effort?
1
c++boostipcshared-memoryboost-interprocess
for 3) why do you need special code for windows? Whats wrong with using shared_memory_object, whether or not it is backed by a file? Afterall windows shared memory is not that different with it being backed in the pagefile. Do you need to access native shared memory created by an exiting application? From your portability concerns I assume that is not the case, so why not just use shared_memory_object? - Grizzly
No, I don't need to access shm of an existing application. To be honest, I don't really understand in-depth what difference it makes when it's backed up by some file or by pagefile. So you say there's not much performance loss? - kralyk
From my understanding it shouldn't make that much of a difference. I would also think that if using native shared memory would be that much faster it would have been mentioned somewhare in the boost documentation. So I can't give you a 100% guaranteed answer, but I think it shouldn't have that huge of an impact (btw: just how much data wdo you want to transfer that you would actually notice a drop of performance?) - Grizzly
Ok thanks! I don't know how much data I'll need to transfer. Initially, not much (like kilobytes), but later maybe more. So I guess you're right and it's not an issue right now... - kralyk

1 Answers

1
votes
  1. no that is not bad design. It is a standard way to do so with IPCs. You (usually) don't have access to the naming system and have a kind of list of existing objects like a filesystem.
  2. If I remember well: if you truncate while mapped, there will be memory violations on new invalidated addresses (if memory protection is supported). You don't have to remap, you just have to take care about what you are doing. I'm not sure that you really need to truncate a SHM but that's your problem.
  3. that is not a problem, it just means that the underlying object is a file because standard semantic for SHM include persistence. But don't care, that is boost internals tricks. The semantic is the one you want, so use it to get portability!