Re: asymmetric usage of SysV semaphore, SEM_UNDO
Re: asymmetric usage of SysV semaphore, SEM_UNDO
- Subject: Re: asymmetric usage of SysV semaphore, SEM_UNDO
- From: Terry Lambert <email@hidden>
- Date: Mon, 16 Jan 2006 18:55:48 -0800
On Jan 16, 2006, at 5:47 PM, Alex Sheh wrote:
Hi all,
Through googling I’ve seen some warnings against using SysV
semaphore’s SEM_UNDO flag for asymmetric semaphores – i.e. Process A
acquires sem1 and ProcessB releases sem1. I can see the problem when
one process exits before the other. For instance in the usage case
where Process A is sitting on an acquire operation waiting for
Process B to release the semaphore - if ProcessB releases sem1 and
exits before ProcessA acquires sem1, then upon exit ProcessB will
acquire sem1 via SEM_UNDO (opposite of release), and "steal" it
before ProcessA has a chance to grab sem1.
However, if Process A and B are expected to exit at the same time,
then it doesn’t seem like this should be an issue. Even if either
Process A or B exit abnormally, as long as we terminate the
remaining process (which could possibly be hung), then the SEM_UNDO
flag (set for acquire and release ops) would result in the semaphore
value being rolled back via undo to its initial value, say zero. So
when Process A and B are launched again, their semaphore value
should start out at zero, and allow for proper synchronization
(hopefully). As long as the processes are terminated and launched
again, I don’t see the possibility of a corrupt semaphore value in
the system.
Am I missing something here? I’ve come across warnings against
asymmetric usage of SysV semaphore’s SEM_UNDO operation, so I’m
quite cautious about using it. But if my above analysis is correct,
in the context of my particular needs (processes are expected to
exit at same time, and recovery involves terminating all remaining
processes and re-launching all process), does it seem okay to use
them? What exactly is the major problem case when using asymmetric,
SysV, and SEM_UNDO? Is the behavior platform-specific (my apps are
running on MacOSX, but I’m curious because I read that the Linux
implementation prevents SEM_UNDO from decrementing a sem value past
zero, which would be problematic for my needs since this could
corrupt the semaphore value)? Thank you kindly for your help. If
another mailing list is more appropriate for this question, please
let me know.
Down adjustments are clamped at 0; up adjustments are not clamped.
It's therefore possible to have an out of order operation because of
asymmetric use that results in multiple simultaneous operations in
racing exiting processes that end up leaving the semaphore at a net
positive value.
This same race exists on most BSD-based systems, and, as you note,
also in Linux, since it prevents underflow.
This race is why most authors suggest you not use SEM_UNDO with
asymmetric semaphore use between processes. If you use them
symmetrically, you are at least guaranteed that the resource tracking
on he undo operations will happen in such a ways as to not leave the
value hanging out there. Even if your code works on one platform,
there's no guarantee of portability to another platform, or even from
release to release of an OS from a given vendor, if bug fixes are
needed in the area, so you are pretty much just asking for trouble
mixing models.
You are much better off explicitly setting the value at startup time
via semctl(...,..., SETALL,..) or SETVAL, if you are talking a single
semaphore. In actual practice, you are probably better off using
IPC_RMID, and semget to delete and recreate the semaphores, rather
than expecting them to persist and have reasonable values (i.e. using
ftok() on a known path to get the key, destroying the semaphore set,
and restarting with a clean set, following a crash). If your program
is crashing anyway, there's no guarantee that the order of shutdown
for two crashing programs is going to be useful.
-- Terry _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden