On 5 May 2014 at 22:31, Peter Dimov wrote:
But you've merely constructed the lambda, not executed it. The compiler is surely right to think that without it being executed that result's value will be constant?
In the example in the docs, you are passing the lambda to another thread, which means that you're passing a reference to 'result' to another thread. So it's no longer local.
I still don't see how the compiler knows anything about that. The compiler can see a syscall, that is all. If thread() doesn't do a syscall, all it can see is a store of a capturing lambda type to some memory location. I already explained why I don't see the compiler auto-volatiling every captured local variable as a result.
Consuming permits let you grant either with or without the mutex.
Non-consuming permits will deadlock if you grant holding the mutex because of the guarantee of blocking until the release of all current waiters.
OK. Here you go then.
* Initially P is 0 and p_mutex is unlocked.
* Tc1, Tc2 lock p_mutex and call wait.
* Tp1 locks p_mutex, sets P=1, unlocks p_mutex and gets suspended.
* Tp2 locks p_mutex, sets P=1, unlocks p_mutex and calls notify_one.
* Tc1 is unblocked with p_mutex locked, returns from wait, gets suspended.
* Tp1 is resumed and calls notify_one.
* Tc2 is unblocked and blocks on p_mutex, which is held by Tc1.
* Tc1 is resumed, sees P=1, sets P=0, unlocks p_mutex.
* Tc2 is unblocked, sees P=0.
Your original point was that the docs should not claim no need for predicate testing during waits. I asserted this because unlike a condvar, permits carry state i.e. their own predicate, so predicate testing - where that predicate is for indicating a thread can continue - is unnecessary. In your example above, you add an unnecessary predicate which duplicates the one in the permit, except it gets out of sync with the permit's state because you don't take measures to ensure they stay in sync. No wonder it deadlocks so. I therefore don't get what point you're making? What should I change in the docs to alleviate your concern? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/