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 Unix shm_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.