Vladimir Prus wrote:
Ben Hutchings wrote:
after which thread B will pick up the lock and write the data and
resets the boolean flag. After releasing the lock, threads A will immediately try to re-acquire the lock.
<snip>
You might find that this works on your development machine, but it will likely fail elsewhere. There is no guarantee that releasing a mutex that's blocking another thread is will wake that other thread.
This is an interesting question. The situation is that thread B waits on a mutex and thread A first released mutex and then locks it again. POSIX says that:
If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock() is called, resulting in the mutex becoming available, the scheduling policy is used to determine which thread shall acquire the mutex.
Which I interpret as saying that if B waits on the lock when A releases it, B will acquire the lock, as it's the only thread waiting on the lock. Am I wrong? <snip>
I think you are right, but Boost.Threads isn't just a wrapper for pthreads. Also, it strikes me now that there is also no guarantee that thread B is blocked by the time thread A unlocks the mutex; it could be descheduled immediately after it sets the volatile flag, allowing A to unlock and relock straight away. I don't expect the results of this to be disastrous, as A will presumably give B another chance the next time it polls the flag, but it's not a very reliable means of communication. Ben.