interprocess_shared_memory
Overview
cbeam::memory::interprocess_shared_memory
provides a simpler alternative to Boost’s shared memory objects, particularly under Windows, where it uses the native file mapping API, avoiding any external file creation. On Unix-like systems, it creates a named POSIX shared memory segment, with consistent cleanup once no processes are attached.
Key Features
- Cross-Platform: Clean wrappers around Windows
CreateFileMappingA
/MapViewOfFile
or Unixshm_open
/mmap
. - Mutex Integration: Includes a
named_recursive_mutex
to lock the shared region if needed for concurrency. - Auto-Unlink / Auto-Cleanup: The shared memory is deallocated as soon as the last referencing process closes it (no leftover files or persistent OS-level objects).
- No Boost Dependency: Contrasts with
boost::interprocess::shared_memory_object
, which depends on file-based synchronization and special directories.
Boost Comparison
Boost’s interprocess::shared_memory_object
introduces complexities on Windows (e.g., storing files in C:\ProgramData\boost_interprocess
) or requiring explicit unlink calls. Cbeam’s approach uses the native Windows shared memory model:
- No need for permission configuration in
C:\ProgramData\boost_interprocess
. - The memory can be accessed only by processes in the same user session, improving security.
Usage
#include <cbeam/memory/interprocess_shared_memory.hpp>
int main() {
cbeam::memory::interprocess_shared_memory sharedMem("mySharedSegment", 1024);
// Acquire a lock if needed
{
auto guard = sharedMem.get_lock_guard();
// read or write to sharedMem.data() which is 1024 bytes
// ...
}
return 0;
}
Considerations
data()
returns a pointer to the allocated region. You may place your own data structures there or use advanced container classes from Cbeam (like stable interprocess containers).- The internal lifetime matches the process usage. When all processes exit, the OS cleans up the segment.