[ILUG] OT : Semaphore Key creation

[Philip Reynolds]

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
probably others:

	1. Using the port number as a unique identifier to generate
a key
	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:

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>

int
main(int argc, char *argv[])
{
        int semid1, semid2;

        semid1 = semget(IPC_PRIVATE, 1, 0700);
        semid2 = semget(IPC_PRIVATE, 1, 0700);

        while(1) {}
}

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
worry about.

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 ... ) 
	fork()

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
	  semid.
	- 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.

HTH,

-- 
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