Ben Hutchings wrote:
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.
I wonder if Windows semantics differ... the docs for ReleaseMutex are not very clear on this.
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.
Yes, that's what I though too.
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.
I interpret the intentions like this: 1. The simplest way is to for thread A to push data after each job is done, and for thread B to get data when it wants to, using mutex to protect data. 2. Another approach is for thread A to always hold the mutex, and briefly unlock it after each job is done. Thread B will wait on the mutex, and eventually A will unlock the mutex when B waits on it, so B will acquire the mutex and do the job. 3. Even more complex approach is to make A unlock the mutex only if some variable is set. In that case, the situation where B sets the flag, A releases and locks the mutex and then B tries to lock the mutex is harmless -- B will get the mutex on the next cycle. However, this is rather complicated design! - Volodya