Re: [boost] [thread] condition::notify with unlocked mutex

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-12-07 11:25:33

Yuval Ronen wrote:

> Ok, while trying to understand this, I made a list of kernel calls in
> each scenario. Both scenarios contain two threads: Thread1 is waiting
> on a CV. Thread2 locks the mutex (as it should), changes the CV
> predicate, notifies the CV, and unlock the mutex, either before or
> after the notify. Lets see what Thread2 does:
>
> Scenario #1
> -----------
> 1. calls mutex_lock (kernel)

mutex_lock only goes to the kernel if the mutex isn't free.

> 2. changes predicate
> 3. calls mutex_unlock (kernel)

Likewise, mutex_unlock only goes to the kernel if between the lock and the 
unlock another thread has tried to lock the mutex and has been blocked by 
the kernel.

> 4. calls cond_signal (kernel changes thread1 state from "blocked" to
> "ready"
>
> Scenario #2
> -----------
> 1. calls mutex_lock (kernel)

No difference here.

> 2. changes predicate
> 3. calls cond_signal (kernel changes thread1 state from "blocked on
> cond" to "blocked on mutex"
> 4. calls mutex_unlock (kernel changes thread1 state from "blocked" to
> "ready"

Guaranteed kernel call since at least one thread, thread1, is blocked 
waiting for the mutex.

> Another thing (in addition to the better chance of avoiding bugs, as I
> explained in previous post) is that I believe that Scenario #2 better
> serves the "fairness" ideal, as described by Anthony Williams in
> http://lists.boost.org/Archives/boost/2006/10/112609.php.

You are free to use scenario #2 if you like. I'm just saying that it isn't 
the only option. :-)