Am 24.03.2014 um 16:53 schrieb Koehne Kai <kai.koe...@digia.com>:

> 
> 
>> -----Original Message-----
>> From: interest-bounces+kai.koehne=digia....@qt-project.org
>> [mailto:interest-bounces+kai.koehne=digia....@qt-project.org] On Behalf Of
>> Bob Hood
>> Sent: Monday, March 24, 2014 4:49 PM
>> To: Thiago Macieira; interest@qt-project.org
>> Subject: Re: [Interest] QThread
>> 
>> [...]
>> I actually use the "volatile" tag to tell the compiler that it cannot 
>> optimize (i.e.,
>> make compile-time assumptions about) the variable that it decorates.
>> Does std::atomic have the same meaning for optimizations?  I can't get a 
>> clear
>> picture of this by a (cursory) Google.
> 
> To cite
> https://stackoverflow.com/questions/12878344/volatile-in-c11

Good link!

I /knew/ that this discussion about “volatile” would pop up again; we had it 
several months (years?) ago. But it’s a good thing, since I forgot already what 
the outcome of that discussion was ;)
Here is another reference:

 
http://stackoverflow.com/questions/2484980/why-is-volatile-not-considered-useful-in-multithreaded-c-or-c-programming

Summary: don’t use volatile, use proper thread synchronisation mechanisms such 
as std::atomic or QMutex, even for the “simple case” of flagging a “You can 
stop now”-situation to the worker thread!

The reason was already pointed out by Thiago (just like last time ;)): you 
never know when that “eventually” will happen – depending on the CPU 
architecture maybe never: as long as no “memory barriers” are involved the 
value of “m_youCanStopNow” might be stuck “forever” in some CPU (Core) cache.

That also renders the use of “volatile” superfluous, as the compiler won’t 
“optimise away” a read from a variable which is “surrounded” by memory barriers 
(if it does, it is a compiler bug).

Cheers, Oliver
 
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to