Bryan O'Donoghue <bryano at europlex.ie> 57 lines of wisdom included:
> ftok(), if I'm not mistaken, does *not* gaurantee, a unique key for the
> likes of semget();
Yes, you're right, ftok() keys do not guarantee uniqueness.
> What is the accepted methodology/wisdom for generating unique sem/shm keys?
I don't think there is one. I've seem mainly three, but there are
1. Using the port number as a unique identifier to generate
2. Using ftok()
3. Using IPC_PRIVATE
Each way can work, but yes you're right, 1&2 do not guarantee that
the key is unique. This is left up to you, the programmer.
What you might consider is the IPC_EXCL bit that you pass along with
IPC_CREAT. If the key already exists, you'll get an error. See
shmget(2) under EEXIST.
If you use IPC_PRIVATE, the operating system selects the next
available shared memory block.
e.g. from this example program:
main(int argc, char *argv)
int semid1, semid2;
semid1 = semget(IPC_PRIVATE, 1, 0700);
semid2 = semget(IPC_PRIVATE, 1, 0700);
I'm getting the following:
------ Semaphore Arrays --------
key semid owner perms nsems status
0x00000000 0 phil 700 1
0x00000000 32769 phil 700 1
If you keep adding more and more semget calls, you'll get different
semid's every time. The key however is the same.
FreeBSD is a bit more logical in it's assignment, the semaphore IDs
go up sequentially IIRC. There may be a reason why Linux hasn't done
it this way but I'm unaware of it. Either way, those implementation
details are irrelevant, it's the ends and not the means you want to
The problem above however is how would two processes get the same
semid, the answer is that they wouldn't. So you need to pass the
semid somehow, either by fork-exec'ing, writing to disk or by some
other process. IPC_PRIVATE is really typical in a parent-child
relationship where the sequence of calls would be:
semid = semget(IPC_PRIVATE ... )
here the semid is shared by the parent and child.
> More to the point, if I do an "ipcs" and get.
>> ------ Shared Memory Segments --------
> key shmid owner perms bytes nattch status
>>> 0x00000000 557059 beths 600 393216 2 dest
>> 0x00000000 589828 root 600 4331 0
>>> All with the same key, my thinking is it dones't really matter 'what'
> the key is, so long as the semid/shmid is unique... but I could be wrong.
The key is normally a long integer. In this case, it looks like the
processes gave the key IPC_PRIVATE which signifies creating a new
semaphore, as explained above.
> I'm a bit confused here Batman, shouldn't the key be unique and not just
> the sem/shm id?
When you specify the key, if you use:
- IPC_PRIVATE, then you'll create a new object with a unique
- any other integer plus IPC_CREAT means a new IPC object is
created. This is not guaranteed to be unique.
ftok() means you use method 2. You generate a unique integer (most
commonly a long) and pass it as the key. It's possible to create a
small algorithm that passes IPC_EXCL and enumerates a number of
different keys from a starting position.
All of this is from memory, so E&OE.
Philip Reynolds | RFC Networks Ltd.
philip.reynolds at rfc-networks.ie | +353 (0)1 8832063
http://people.rfc-networks.ie/~phil/ | www.rfc-networks.ie
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!