On Mon, Dec 7, 2009 at 7:16 PM, Stonewall Ballard
On Dec 7, 2009, at 7:56 PM, Steven Watanabe wrote:
AMDG
Gabriel Redner wrote:
I'm involved in a bit of a dispute in which a colleague is claiming that 'volatile' is necessary to make certain synchronization patterns correct. As part of my response I pointed out that the boost.thread examples don't use it, but he maintains his position - saying that the examples are flawed. I'm frankly somewhat out of my element here, and I'd like to get input from people who have presumably thought about this stuff a good deal.
The example in question is here, under "synopsis": http://www.boost.org/doc/libs/1_41_0/doc/html/thread/synchronization.html#th...
The claim is that 'volatile' is needed on the boolean, otherwise the compiler might cache the boolean in a register, and the loop would never exit. He cites for support two articles:
http://www.ddj.com/cpp/184403766 https://www.securecoding.cert.org/confluence/display/seccode/DCL17-C.+Beware...
Who's right?
volatile is not needed in that example because access is protected by a mutex.
In this example: ---- boost::condition_variable cond; boost::mutex mut; bool data_ready;
void process_data();
void wait_for_data_to_process() { boost::unique_lockboost::mutex lock(mut); while(!data_ready) { cond.wait(lock); } process_data(); } ----
What prevents the compiler from leaving data_ready in a register while in the while loop, hence never seeing some other thread setting it? The mutex is released while waiting on the condition, so data_ready is not protected while in cond.wait().
There are a few things it could be doing so that it could look like that and still be correct: a) An explicit barrier intrinsic, which is a more optimal way to get volatile semantics. (ie. VC++'s _ReadWriteBarrier) b) An atomic intrinsic which the compiler recognizes as an implicit barrier. (ie. VC++'s _InterlockedCompareExchange) c) A function with unknown side effects is being called somewhere. (ie. anything the compiler doesn't have a full definition of... like an operating system's own mutex functions) -- Cory Nelson http://int64.org