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: Steve Checkoway <email@hidden>
- Date: Thu, 2 Apr 2009 08:07:47 -0700
On Apr 2, 2009, at 2:03 AM, Terry Lambert wrote:
On Apr 1, 2009, at 9:31 PM, Steve Checkoway <email@hidden> wrote:
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.
Of course.
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?"...
Thanks. The engineering perspective was what I was interested in.
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.
After reading your response and the notes for fp_getfsem, I believe I
see the issues. Thanks for taking the time to explain.
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.
I'm afraid I neither need the feature nor have the money to buy a
bunch of Xserves. I was just curious about its absence.
--
Steve Checkoway
"Anyone who says that the solution is to educate the users
hasn't ever met an actual user." -- Bruce Schneier
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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