• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: What if process crashes while holding a locked semaphore?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


  • Follow-Ups:
    • Re: What if process crashes while holding a locked semaphore?
      • From: Steve Checkoway <email@hidden>
References: 
 >Re: What if process crashes while holding a locked semaphore? (From: David Gatwood <email@hidden>)
 >Re: What if process crashes while holding a locked semaphore? (From: Terry Lambert <email@hidden>)
 >Re: What if process crashes while holding a locked semaphore? (From: Steve Checkoway <email@hidden>)

  • Prev by Date: Re: debuggging a recurring system freeze (syslog redir, ktrace?)
  • Next by Date: Re: What if process crashes while holding a locked semaphore?
  • Previous by thread: Re: What if process crashes while holding a locked semaphore?
  • Next by thread: Re: What if process crashes while holding a locked semaphore?
  • Index(es):
    • Date
    • Thread