site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Thread-index: AcYbEYiNh/rVP3rORiKHVsxTnyux+gAtwOHA 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:tlambert@apple.com] Sent: Monday, January 16, 2006 6:56 PM To: Alex Sheh Cc: darwin-kernel@lists.apple.com 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com