Re: pthread_cond_wait() missing broadcast?
Re: pthread_cond_wait() missing broadcast?
- Subject: Re: pthread_cond_wait() missing broadcast?
- From: Jim Magee <email@hidden>
- Date: Wed, 9 Jan 2008 07:56:20 -0500
On Jan 7, 2008, at 2:49 PM, Pierre Baillargeon wrote:
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()).
--Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden