Semaphore tutorial?

[Roy Smith]

Does anybody have a good tutorial for how SysV semaphores work,
specifically the semop() function? I've read the description in
Stevens' Unix Network Programming several times, but I'm still totally
baffled.

What does SEM_UNDO do? Stevens describes how it affects the kernel's
semadj variable, but I don't understand what the purpose of that is.

Why would you want to have a value for sem_op which is anything other
than -1, 0, or +1? If you wanted to obtain a resource, what would be
the purpose of setting it to -42 instead of -1?

Why would you ever want to have more than one semaphore in a set?

Lastly, I'm working on a Linux box which appears to have the SysV
versions of message queues, semaphores, and shared memory, in addition
to the posix semaphores. Given that the posix semaphores look a whole
lot simplier to use than the SysV kind, I'm tempted to mix and match,
i.e. use the SysV shared memory (because it's the only kind available)
with posix semaphores (because they're simplier to use). Any reason not
to do that?

[Marc Rochkind]

On Sun, 20 Jul 2003 21:19:52 -0400, Roy Smith <roy@panix.com> wrote:

> Does anybody have a good tutorial for how SysV semaphores work,
> specifically the semop() function? I've read the description in Stevens'
> Unix Network Programming several times, but I'm still totally baffled.
>

I have one in progress... can you wait a few months?

> What does SEM_UNDO do? Stevens describes how it affects the kernel's
> semadj variable, but I don't understand what the purpose of that is.

This is a rollback mechanism that allows what a process did to a semaphore
to be undone if it exits abnormally.

>
> Why would you want to have a value for sem_op which is anything other
> than -1, 0, or +1? If you wanted to obtain a resource, what would be the
> purpose of setting it to -42 instead of -1?

Suppose the semaphore indicates the number of thingies available. If you
produce 17 of them, you would bump the number by 17.

>
> Why would you ever want to have more than one semaphore in a set?
>

It's possible for more than one semaphore to be needed (one for each
resource to be controlled, say). The advantage of sets is that a single
semop is an atomic operation.

> Lastly, I'm working on a Linux box which appears to have the SysV
> versions of message queues, semaphores, and shared memory, in addition to
> the posix semaphores. Given that the posix semaphores look a whole lot
> simplier to use than the SysV kind, I'm tempted to mix and match, i.e.
> use the SysV shared memory (because it's the only kind available) with
> posix semaphores (because they're simplier to use). Any reason not to do
> that?
>

Mixing and matching is perfectly OK.

However, check your Linux again. My version of Linux has POSIX semaphores
only as un-named, non-shared semaphores. (That is, sem_open is missing, and
sem_init doesn't support the pshared argument.) Perhaps your Linux is more
complete.

My recommendation is to wrap the very elaborate Sys V semaphores in simple
functions that look more like the POSIX semaphores: post and wait, and to
use them that way. Go for the fancier features (increments other than one,
and more than one in a set) only if your application absolutely requires
it.

System V semaphores have one other problem that Stevens explains very well
(p. 284. of UNIX Network Programming: Interprocess Communications): A new
semaphore is not initialized, and there is a race condition between its
creation and the follow-on call to initialize. Stevens explains a
complicated (but essential) way to program around this.

--Marc

[Casper H.S. Dik]

Roy Smith <roy@panix.com> writes:

>What does SEM_UNDO do? Stevens describes how it affects the kernel's
>semadj variable, but I don't understand what the purpose of that is.

"semadj" limits how much of "SEM_UNDO" can be done; "SEM_UNDO" allows
you to create a process which is "semaphore value neutral" when it
is killed or exists unexpectedly.

>Lastly, I'm working on a Linux box which appears to have the SysV
>versions of message queues, semaphores, and shared memory, in addition
>to the posix semaphores. Given that the posix semaphores look a whole
>lot simplier to use than the SysV kind, I'm tempted to mix and match,
>i.e. use the SysV shared memory (because it's the only kind available)
>with posix semaphores (because they're simplier to use). Any reason not
>to do that?

None that I can think of.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.