C语言 如果访问共享内存的关键是 shmget() 的返回值，那么拥有 key_t 的意义何在？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4175379/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the point of having a key_t if what will be the key to access shared memory is the return value of shmget()?
提问by devoured elysium
When using shared memory, why should we care about creating a key
使用共享内存时，为什么要关心创建密钥
key_t ftok(const char *path, int id);
in the following bit of code?
在下面的代码中？
key_t key;
int shmid;
key = ftok("/home/beej/somefile3", 'R');
shmid = shmget(key, 1024, 0644 | IPC_CREAT);
From what I've come to understand, what is needed to access a given shared memory is the shmid, not the key. Or am I wrong? If what we need is the shmid, what is the point in not just creating a random key every time?
根据我的理解，访问给定共享内存所需的是shmid，而不是密钥。还是我错了？如果我们需要的是shmid，那么不只是每次都创建一个随机密钥有什么意义？
Edit
编辑
@Beej's Guide to Unix IPCone can read:
@ Beej 的 Unix IPC 指南可以阅读：
What about this
keynonsense? How do we create one? Well, since the typekey_tis actually just along, you can use any number you want. But what if you hard-code the number and some other unrelated program hardcodes the same number but wants another queue? The solution is to use theftok()function which generates a key from two arguments.
这个
key废话怎么办？我们如何创建一个？好吧，由于类型key_t实际上只是 along，您可以使用任何您想要的数字。但是，如果您对数字进行了硬编码，而其他一些不相关的程序对相同的数字进行了硬编码，但想要另一个队列呢？解决方案是使用ftok()从两个参数生成密钥的函数。
Reading this, it gives me the impression that what one needs to attach to a shared-memory block is the key. But this isn't true, is it?
读到这里，它给我的印象是，需要附加到共享内存块的东西才是关键。但这不是真的，不是吗？
采纳答案by Toby
Yes, you need to use the shmid to access the shared memory (using shmat()) after you've opened it using shmget(). But the specific block of shared memory that you'll be accessing is based on the key that you are using i.e. different process wishing to communicate via the shm will need to use the same key. If you just used a random number as a key, you might get a clash with some other unrelated program.
是的，shmat()在使用shmget(). 但是您将访问的特定共享内存块基于您使用的密钥，即希望通过 shm 进行通信的不同进程将需要使用相同的密钥。如果您只是使用随机数作为密钥，您可能会与其他一些不相关的程序发生冲突。
I was going to suggest taking a look at Beej's Guide to IPCbut I see you've already found it :)
我打算建议看看Beej 的 IPC 指南，但我看到你已经找到了 :)
回答by R.. GitHub STOP HELPING ICE
The whole System V IPC system is full of bad designs like this. (By bad designs, I mean a tiny namespace for shared resources where you have to rely on stupid tricks like ftokto get a key and pray it doesn't happen to conflict with any other keys in use.)
整个 System V IPC 系统充满了这样的糟糕设计。（糟糕的设计是指共享资源的小命名空间，您必须依靠愚蠢的技巧ftok来获取密钥，并祈祷它不会与正在使用的任何其他密钥发生冲突。）
If possible, I would pretend it doesn't exist and use POSIX shared memory instead whenever possible (and likewise POSIX thread synchronization primitives in place of System V semaphores). The only instance I can think of where you need System V shared memory is for the X shared-memory image extension and perhaps other X extensions.
如果可能，我会假装它不存在，并尽可能使用 POSIX 共享内存（同样使用 POSIX 线程同步原语代替 System V 信号量）。我能想到的唯一需要 System V 共享内存的例子是 X 共享内存映像扩展和其他 X 扩展。
Edit:To better answer OP's question about the purpose of ftok: key_tis usually 32-bit and yes you could just pick a 32-bit number yourself, but the problem is that humans are not equally likely to pick all numbers, and the chance of collision is way too high. ftoklets you choose a file (intended to be one unique to your application) and an integer and hash the file's inode number with your chosen integer, which should result in much more even distribution of key choices across the key space. Of course you could also just choose a key with randas long as you have a way of passing the result to other processes that need to attach the shared memory.
编辑：为了更好地回答 OP 关于以下目的的问题ftok：key_t通常是 32 位，是的，您可以自己选择一个 32 位数字，但问题是人类选择所有数字的可能性不同，并且发生碰撞的可能性太高了。ftok允许您选择一个文件（旨在成为您的应用程序唯一的一个文件）和一个整数，并使用您选择的整数散列文件的 inode 编号，这将导致在键空间中键选择的分布更加均匀。当然，您也可以只选择一个键，rand只要您有办法将结果传递给需要附加共享内存的其他进程。
回答by caf
shmidvalues are only valid in the context of a single process, whereas the same key_tvalue in different processes will allow them to open the same shared memory segment.
shmid值仅在单个进程的上下文中有效，而key_t不同进程中的相同值将允许它们打开相同的共享内存段。
That's essentially why you need a key_t- as a cross-process way of naming a shared memory segment. As for ftok(), as the other answers have noted, that's used to reduce the probability of two unrelatedgroups of processes using the same key_tvalue.
这就是为什么你需要一个key_t- 作为命名共享内存段的跨进程方式的原因。至于ftok()，正如其他答案所指出的，它用于降低两个不相关的进程组使用相同key_t值的可能性。
