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?
@Beej's Guide to Unix IPC one can read:
What about this
key
nonsense? How do we create one? Well, since the typekey_t
is 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.
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?
If successful, shmget() returns a nonnegative integer, namely a shared memory identifier. A shared memory identifier does not exist for the argument key specified and the value of argument size is less than the system-imposed minimum or greater than the system-imposed maximum.
The maximum size of this teraspace shared memory segment is 268 435 456 bytes (256 MB).
The shmget function is used to create a new shared memory segment or to locate an existing one based on a key. Shared memory segments are memory areas which can be shared by several processes and which, once created, continue to exist until explicitly deleted using the shmctl function.
Unix requires a key of type key_t defined in file sys/types. h for requesting resources such as shared memory segments, message queues and semaphores. A key is simply an integer of type key_t; however, you should not use int or long, since the length of a key is system dependent.
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 ftok
to get a key and pray it doesn't happen to conflict with any other keys in use.)
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.
Edit: To better answer OP's question about the purpose of ftok
: key_t
is 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. ftok
lets 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 rand
as long as you have a way of passing the result to other processes that need to attach the shared memory.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With