选择共享内存或 unix 信号量键的惯用方式答案

【问题标题】：Idiomatic way to chose shared memory or unix semaphore key选择共享内存或 unix 信号量键的惯用方式
【发布时间】：2016-04-28 06:03:32
【问题描述】：

为shmget 或semget 函数选择键的惯用方式是什么？

如何确定其他进程没有使用相同的密钥？

是的。我知道一个大的随机数很可能不会被其他人使用，但是没有防弹的方法来选择它吗？

【问题讨论】：

【解决方案1】：

也许您知道有一个函数ftok 可以让您从文件路径中获取密钥。所以拥有“个人”密钥的问题是找到一个“个人”文件。保证不同的文件有不同的密钥。一个习惯用法可以是创建一个临时文件（借助tmpnam?），或者创建一个隐藏在某个私有目录中的文件并将其与ftok 一起使用。

【讨论】：

是的，我就是这样想的，但对我来说看起来太老套了。只是为了获取密钥而创建一个文件（ftok 需要真实存在的文件）是不是有点奇怪？但看起来这是最好的选择。
别让我觉得太 hackish，毕竟已经有一个具有唯一 ID 的空间，为什么不将它用于多种用途呢？而且一个空文件占用的空间和cpu时间非常少......
请注意，ftok（自然）不保证不同文件（和 proj_id）的不同值，但相同文件只保证相同的值。对于同时存在的文件，该值不同只是手册页中的“应该”。
错误，打开组：ftok() 函数应为命名同一文件的所有路径返回相同的键值，当使用相同的 id 值调用时，并在以下情况下返回不同的键值调用 不同的 id 值或 命名不同文件的路径 同时存在于同一文件系统中。
这也只是一个“shall”。只要您拥有超过 2^24 个文件（32 位 key_t 减去 8 位项目 ID），就无法保证这一点。考虑到设备 ID 也可能发挥作用（手册页建议），少于 2^24 个文件就足够了，也许只有 2^16 个文件就足够了（我的系统目前在 @987654324 上有 ~2^20 个文件@，一个新的 debian 大约有 2^14)，因此冲突必须存在。并且只有在 inode 被顺序分配并在释放时重新使用时才这样做。 ftok 是一个 32 位的散列函数，因此会发生冲突，必须为此做好准备。

【解决方案2】：

首先在分配共享内存或信号量时使用标志IPC_CREAT 和IPC_EXCL。如果已存在具有给定键的共享内存段，shmget 命令将失败。反复尝试使用新的随机密钥获取共享内存段，直到成功为止。

现在您必须找出将您使用的密钥传达给其他进程的方法。正如你建议使用随机数，我假设你有这样的方式。

【讨论】：