Re: What if process crashes while holding a locked semaphore?
Re: What if process crashes while holding a locked semaphore?
- Subject: Re: What if process crashes while holding a locked semaphore?
- From: Terry Lambert <email@hidden>
- Date: Thu, 02 Apr 2009 02:03:58 -0700
- Delivered-to: email@hidden
- Delivered-to: email@hidden
On Apr 1, 2009, at 9:31 PM, Steve Checkoway <email@hidden> wrote:
On Apr 1, 2009, at 4:59 PM, Terry Lambert wrote:
We don't support unnamed POSIX semaphores, we don't support
sem_getvalue(), and if you try you get a SIGSYS, which if you don't
catch it, you're program exits. We also don't guarantee correct
error semantics for the POSIX named semaphores we do have, since if
we can't run the conformance tests because we don't support unnamed
semaphores, we can't tell if the errors we return are correct or not.
Is there a technical reason that Darwin doesn't support POSIX
unnamed semaphores or it's just not a priority since they're not
necessary?
I can give you technical information about why I haven't personally
done it, but realize I am not speaking officially in any capacity by
doing so.
With that in mind, I'll try to answer your questions from an
engineering perspective, rather than putting it as the more pragmatic
"if Apple implemented POSIX unnamed semaphores, how many X Serves
would you buy?"...
They aren't required for UNIX conformance because they are not
mandatory interfaces per Appendix 9 of the Single UNIX Specification,
and there are lots of alternatives, most of them with better overall
semantics, which this tread has amply demonstrated. Most portable and
historical software uses System V semaphores, since POSIX semaphores
are relatively new, so there's little software portability incentive.
The software which does like to use them is typically based on GNU
autoconf/automake which typically uses linkage tests to find
interfaces and blows it by doing that and ignoring <unistd.h>
contents, since historical conformance with older versions of the
specification permitted stub functions which errored out, and the
linkage tests only check linkability rather than functionality. So
basically the software that wants them usually fails to conform to the
standards which would have allowed them to be used safely and reliably
in the first place.
Then there is the little problem of binary backward compatibility for
POSIX named semaphores, if the error or success returns don't happen
to match the standard once testing of a full implementation became
possible.
As a Mac OS X implementation detail, sem_t is the required data type
for both POSIX named semaphores and POSIX unnamed semaphores according
to the standard. The sem_t definition has historically been a 32 bit
value containing an fd cast to a pointer, which is problematic for
maintaining binary and source backward compatibility (hint: think
symbol decoration) for named semaphores while at the same time
permitting typical usage of unnamed semaphores. Specifically, typical
usage of unnamed semaphores is to use them as an IPC synchronization
mechanism between otherwise unrelated programs by allocating a shared
memory region shared between them of sizeof(sem_t)
*number_of_semaphores_desired, and the casting the base address of
that memory region to a (sem_t *) and indexing off that to get a
semaphore index in the range 0..(number_of_semaphores_desired - 1).
The implementation problems should now be obvious. They are not
insurmountable; I sometimes pose how to resolve the conflicting goals
involved as an interview question. 8-). But there isn't really a very
obvious fix I'd call elegant, either.
Maybe someone will surprise me someday, or maybe an outside developer
will attach elegant code capable of balancing the conflicting goals to
a bug report the next time they request the feature, or maybe someone
will contract to buy a bunch of X Serves.
-- 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