site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jan 7, 2008, at 2:49 PM, Pierre Baillargeon wrote: --Jim _______________________________________________ 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... I've tried to follow the code of __pthread_cond_wait() in the Darwin source code, but I've been stumped by the fact that the mutex being passed in is not explicitly unlocked anywhere! The variable is checked to verify that it is indeed a mutex but is not otherwise used anywhere else in the code, making me wonder where and how it can possibly be released. I've gone down to wait_queue_assert_wait64_locked(). Is the unlock somehow implicit? 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()). This email sent to site_archiver@lists.apple.com