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?

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

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.