2014-05-04 1:13 GMT+04:00 Niall Douglas <s_sourceforge@nedprod.com>:
Dear Boost,
Review and commentary upon a proposed new Boost object, boost::permit<> is invited.
I've just started to read the documentation and that's what looks wrong: ... And the compiler's optimiser is permitted by the standard to believe that result has not changed between its initialisation and the first test of its value, so in fact the optimiser could compile this instead by eliding the first test of result under the assumption that the predicate will always be false for its first execution: do { wait(guard);} while(!pred()); ... This can not happen because thread constructor is a `release` operation: // main thread int result=0; boost::thread(f); // release [2] boost::unique_lock<decltype(lock)> guard(lock); // acquire [1] done.wait(guard, [&result] { return result!=0; }); // new thread // acquire - from thread constructor [2] boost::lock_guard<decltype(lock)> guard(lock); acquire [1] result=78; // release [1] Compiler is prohibited from moving non-atomic stores past the atomic store-release or perform non-atomic loads earlier than the atomic load-acquire. [1] ISO C++11 30.4.1.2 Mutex types: Synchronization: Prior unlock() operations on the same object shall synchronize with (1.10) this operation. [2] ISO C++11 30.3.1.2 thread constructors: Synchronization: The completion of the invocation of the constructor synchronizes with the beginning of the invocation of the copy of f. -- Best regards, Antony Polukhin