On Sat, 12 Sep 2009, Kevin Van Vechten wrote:
On Sep 12, 2009, at 2:15 AM, Robert Watson wrote:
- libdispatch uses Mach semaphores. In FreeBSD, I've substituted POSIX semaphores. I've run into at least one issue doing so, as libdispatch maintains parallel state and appears not to propagate an initial declared 'value' to the Mach semaphore. Once I understand the problem better, I'll post a more specific query for the Apple folks. Not an issue for a Leopard port.
A count is kept in user space and updated with atomic operations. The general idea is to avoid trapping into the kernel except when blocking is required (or when signaling a blocked thread is required).
There were two things that worried me: (1) The following comment in semaphore.c: // Mach semaphores appear to sometimes spuriously wake up. Therefore, // we keep a parallel count of the number of times a Mach semaphore is // signaled (6880961). (2) That the initial semaphore value, 'value' passed to dispatch_semaphore_create(), isn't propaated to the kernel semaphore when it's allocated on-demand in _dispatch_posix_semaphore_create(). If the kernel semaphore is just the wakeup primitive, this may not be an issue, but I haven't read what's there deeply enough to reason about that yet. An answer from someone who knows already would be most helpful :-). Since POSIX semaphores are already a blended kernel/userspace implementation on FreeBSD, it sounds like I could ditch the userspace mirrored state, although we'll have to see whether that is true of other UNIX systems. Robert N M Watson Computer Laboratory University of Cambridge