shm_overview(7)

💖 shm_overview(7) 💖

okay bestie, sit down, hydrate, because today we're talking about shm_overview — the whole vibe tour of POSIX shared memory. this is section 7, misc info manual energy, and yes it's gonna be cute AND correct. 🫶

---

✨ NAME ✨

shm_overview — the big-picture overview of POSIX shared memory. like, the concept, the lore, the whole thing. 💅

---

🌸 DESCRIPTION 🌸

so here's the tea: the POSIX shared memory API lets processes talk to each other by literally sharing a chunk of memory. same bytes, multiple processes, no cap. 🧠✨

the interfaces that make up this API are:

• shm_open(3) — makes a brand new object or opens one that already exists. it's giving open(2) energy, fr. it hands you back a file descriptor that all the other calls below use. 🌟
• ftruncate(2) — sets the size of the shared memory object. and heads up: a freshly created shared memory object starts out with a length of zero, so yeah, you gotta set this. 🙈
• mmap(2) — maps that shared memory object right into the virtual address space of the process that's calling it. main character move. 👑
• munmap(2) — unmaps it back out of the calling process's virtual address space. bye bestie 👋
• shm_unlink(3) — removes a shared memory object's name. 💀 (not the object itself necessarily — the name, iykyk)
• close(2) — closes the file descriptor that shm_open(3) gave you, for when you're done with it and don't need it anymore.
• fstat(2) — grabs a stat structure describing the shared memory object. among the stuff it hands back: the object's size (st_size), permissions (st_mode), owner (st_uid), and group (st_gid). receipts! 📋
• fchown(2) — for changing the ownership of a shared memory object.
• fchmod(2) — for changing the permissions of a shared memory object.

---

🦋 Versions

POSIX shared memory has been around since Linux 2.4 and glibc 2.2. vintage but thriving, honestly. ⭐

---

🎀 Persistence

POSIX shared memory objects have kernel persistence, which basically means they hang around. a shared memory object will keep existing until:

1. the system gets shut down, or
2. all processes have unmapped the object and it's been deleted with shm_unlink(3)

so yeah, it does NOT just vanish when your program exits. it's committed. 😤

---

🔥 Linking

if your program uses the POSIX shared memory API, you must compile it with:

cc -lrt

because you need to link against the real-time library, librt. don't skip this step, it WILL be a whole thing. 💀

---

🌈 Accessing shared memory objects via the filesystem

on Linux, shared memory objects live inside a tmpfs(5) virtual filesystem, normally mounted under /dev/shm. and since Linux 2.6.19, Linux supports using access control lists (ACLs) to control permissions of objects in that virtual filesystem. fancy. 💅

---

💜 NOTES 💜

• typically, processes have to synchronize their access to a shared memory object — using, for example, POSIX semaphores. no just winging it, bestie, that's how you get chaos. 😭
• System V shared memory (shmget(2), shmop(2), etc.) is the older shared memory API. POSIX shared memory gives you a simpler, better designed interface — but on the flip side, POSIX shared memory is somewhat less widely available (especially on older systems) than System V shared memory. so like, tradeoffs. ⚖️

---

🍓 SEE ALSO 🍓

fchmod(2), fchown(2), fstat(2), ftruncate(2), memfd_create(2), mmap(2), mprotect(2), munmap(2), shmget(2), shmop(2), shm_open(3), shm_unlink(3), sem_overview(7)

---

and that's the whole page, periodt. 🎀 this lil tour came from Linux man-pages 6.20, dated 2025-05-17 — so if you're quoting it, that's the source and the date, bestie. go forth and share that memory responsibly 💖🦋✨