Now Accessing the semaphore

[thumpkidd9]

It is my understanding that after creating the semaphore, you can access it like an array. So if I used the same code as used previously

sid1=semget(IPC_PRIVATE,N,0666|IPC_CREAT);   
if(sid1==-1)perror(0);

it should of made N instances of sid1, and can be accessed by sid1[0-N] no?

Thanks

 

[marsd]

None of this is right.

A SYS V semaphore is a different beast than a mutex.
FAR different, even though it is often used in that
way.
Shared memory is only one of the many 'things' an
S5 semaphore can protect and it's versatility is also
it's complexity. A SYS V semaphore is an IPC primitive
but since it's raison d'etre is not to convey data
but to protect it, it's application and usage is
more 'primitive' than the other sys v ipc IMO.

I'm currently writing a small static source for
future semaphore ops in a particular app, and I'm
sure that many hundreds of programmer groups
have hand coded semaphore api's for their apps
as well, or incorporated generic libraries.

To answer the original question: No, think of the
returned id as a handle for the semaphore. The
semaphore id.
You will provide it for operations using semctl(status,
semaphore specific data settings and gathering,etc..)
and semop,(locking and unlocking).

Now you can use posix style semaphores and even
platform specific adaptations(like futexes), en
capsulated in shared memory, or simply use flock
to do data privacy. I like flock. It's simple and
offers both private(write) and public locking in
a very simple format. YMMV
Using mutexes and semaphores designed for threads
in multi-process programs is a mess IMHO, and I go no further with it than say to use flock(), or design a
workable interface for your sys V semaphores and use
it.