{"id":4920,"date":"2016-06-15T10:10:12","date_gmt":"2016-06-15T10:10:12","guid":{"rendered":"http:\/\/blog.bachi.net\/?p=4920"},"modified":"2016-06-15T15:16:42","modified_gmt":"2016-06-15T15:16:42","slug":"shared-memory-system-v-posix-mmap","status":"publish","type":"post","link":"https:\/\/blog.bachi.net\/?p=4920","title":{"rendered":"Shared Memory: System V \/ POSIX \/ mmap"},"content":{"rendered":"

Beej’s Guide to Unix IPC – Shared Memory Segments<\/a>
\nProgramming in C – IPC: Shared Memory<\/a>
\nSystem V IPC<\/a>
\nOracle Programming Interfaces Guide – System V Shared Memory<\/a><\/p>\n

Don’t use absolute pointer<\/h3>\n

POSIX \/ System v Shared Memory vs Threads Shared Memory<\/a><\/p>\n

In the table I mention the virtual memory mapping issues, what is all that about? It\u2019s about being able to store pointers on the shared memory and whenever that make sense. As I point out the memory can be mapped at different virtual addresses in different processes which means that you can\u2019t use absolute pointer. I think this is better understood with a picture:<\/p>\n\n\n
\"virtualmemory\"<\/a><\/td>\n<\/tr>\n<\/table>\n

In the picture process 1 has stored the 0x70000100 address in the shared memory, that points to somewhere in the shared memory for process 1 but when process 2 reads that address it points to a completely different data in that process that it\u2019s outside the shared memory. That is because the shared memory was mapped at 0x7000000 on process 1 but on 0xFF000000 on process 2.<\/p>\n

This means that when using POSIX shared memory you will have to refrain from storing pointers and need to store offsets or indexes instead (ptrdiff_t, etc). That, in turns, means that you have to engineer your data structures for shared memory.<\/p>\n

stackoverflow<\/h3>\n

Why use SysV or POSIX shared memory vs mmap()?<\/a>
\nHow to list processes attached to a shared memory segment in linux?<\/a><\/p>\n