Re: Need to use "volatile" for accessing variables between threads?
On Jul 28, 12:00 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Greg Herlihy:
On Jul 27, 6:51 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Virchanza:
Volatile is intended to be used where a variable's value
can mysteriously change outside of the normal flow of
code. I'm still not sure whether "a separate thread"
qualifies as being mysterious enough. Some people are
telling me I need volatile. Others are telling me I don't
need volatile. I don't know who to believe. Is it even
possible to get an answer to this question, or is it
simply "undefined"?
It was answered definitively here:
<url:http://www.google.com/search?q=alexandrescu+meyers+volatile>
Presumably, you mean that the Meyers & Alexandrescu paper on
double- checked locking:
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
provides a definitive answer.
And it does. The paper concludes that "volatile" is needed
in order to ensure thread-safety - and in fact is needed
more than once:
"Our earlier analysis shows that pInstance needs to be
declared 'volatile', and in fact this point is made in the
papers on DCLP. However, Sherlock Holmes would certainly
notice that, in order to ensure correct instruction order,
the Singleton object -itself- must be also 'volatile'. This
is not noted in the original DCLP papers, and that's an
important oversight." [pg 7-8].
You might read on... ;-)
Note that that paper really only addresses one side of the
issue: why you can't avoid the lock. It clearly proves that
volatile is not sufficient. It doesn't address the question as
to whether volatile is necessary or not once you use the thread
synchronization primitives. For that, you need to check the
specifications of the thread synchronization primitives, and
threading in your environment. Both Posix and the Microsoft
documentation say clearly that the thread synchronization
primitives ensure memory synchronization, and so volatile is not
necessary (assuming that your compiler is compliant with the OS,
as well as with the C++ standard)---C++0x will take this path as
well.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34