site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 9-Jan-08, at 7:56 , Jim Magee wrote: Thanks for explanation. -- Pierre Baillargeon _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... The unlock needs to be atomic with the marking of the thread waiting on the condition. Since that latter part happens in the kernel, so must the unlock. What you are missing is the logic that converts a mutex being marked busy in user memory, to one being indicated as locked via being assigned a Mach semaphore. That Mach semaphore is then passed into the kernel in the Mach semaphore_{timed}wait_signal() call. That system call atomically marks the thread waiting on the condition's semaphore and pre-posts the mutex's semaphore - effectively unlocking the mutex for future attempts to acquire it (the first of those susequent attempts will have to make a trip to the kernel to acquire it via a semaphore_wait()). The biggest thing I was missing is that the core of pthread_cond_wait is implemented in libc, not in the kernel (in bsd/kern/ pthread_sync.c). I was thus missing a big part of the picture, which explains my confusion. This email sent to site_archiver@lists.apple.com