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: "Alex Sheh" <email@hidden>
- Date: Tue, 17 Jan 2006 16:54:47 -0800
- Thread-topic: asymmetric usage of SysV semaphore, SEM_UNDO
Thank you Terry for the in-depth reply, this is exactly the information
I needed, very elucidating. Now time for me to investigate the ACE
Library's semaphore class implementation (has an implementation using
SysV).
- Alex
-----Original Message-----
From: Terry Lambert [mailto:email@hidden]
Sent: Monday, January 16, 2006 6:56 PM
To: Alex Sheh
Cc: email@hidden
Subject: Re: asymmetric usage of SysV semaphore, SEM_UNDO
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