忽略一些细节，Linux 中有两个可用的低级 SHM API。
我们有older (e.g System V IPC 与 POSIX IPC https://stackoverflow.com/questions/4582968/system-v-ipc-vs-posix-ipc) SysV 接口使用：
- ftok
- shmctl
- shmget
- shmat
- shmdt
and the newerPosix 接口（尽管 Posix 似乎也标准化了 SysV 接口）：
当使用 shm_open() 时，文件和共享内存段之间似乎存在清晰的一对一映射。
但是，如果您使用 shmget()，您可以使用以下命令将多个段关联到单个路径：
key1=ftok(path,1);
key2=ftok(path,2);
shmget(key1,...)
shmget(key2,...)
在这种情况下，文件和段之间的关系怎么办？
给 ftok 的路径只是一个占位符。我看不出它有什么目的。
如果我们将 Unix 哲学视为一切都是文件，为什么这不是一对一的映射？
单独但相关的问题：
中没有这样的建议shm_open https://pubs.opengroup.org/onlinepubs/9699919799/functions/shm_open.html or shm_get https://pubs.opengroup.org/onlinepubs/9699919799/functions/shmget.html
我只能找到模糊的建议，例如：
- https://www.unix.com/linux/53491-shmat-failure-while-using-large-amount-shared-memory.html https://www.unix.com/linux/53491-shmat-failure-while-using-large-amount-shared-memory.html
- https://stackoverflow.com/a/35666695/1569204 https://stackoverflow.com/a/35666695/1569204
我认为 SysV 被认为线程安全性较差。
您是否有任何理由在现代应用程序中更喜欢 SysV（或 posix）？
给 ftok 的路径只是“一切都是文件”传统中的占位符。
经过一段时间的考虑，我认为 mmap 是一个更简单、更安全、更有效的 API。如果可能的话，我个人会完全避免 shmget 等。
shmget()后清理起来特别别扭看到：
- Linux IPC：共享内存回收 https://stackoverflow.com/questions/68408450/linux-ipc-shared-memory-recovery/68408451#68408451
也可以看看：
- Linux 共享内存：shmget() 与 mmap()？ https://stackoverflow.com/questions/21311080/linux-shared-memory-shmget-vs-mmap
- System V IPC 与 POSIX IPC https://stackoverflow.com/questions/4582968/system-v-ipc-vs-posix-ipc
- 如何正确清理和重用SysV共享内存段？ https://stackoverflow.com/questions/66875715/how-do-you-correctly-cleanup-and-re-use-sysv-shared-memory-segments
在一个相关问题中支持 system-v 的一个论点是 Posix 的实施不太广泛。我不知道当时这是不是真的，但现在看来更不可能了。鉴于 GNU/Linux 和 BSD 衍生品的主导地位。如今，即使是传说中“独一无二”的 AIX 也声称符合 Posix 标准。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
