[Interest] QThread

[Till Oliver Knoll]

Am 24.03.2014 um 16:53 schrieb Koehne Kai <Kai.Koehne at digia.com>:

> 
> 
>> -----Original Message-----
>> From: interest-bounces+kai.koehne=digia.com at qt-project.org
>> [mailto:interest-bounces+kai.koehne=digia.com at qt-project.org] On Behalf Of
>> Bob Hood
>> Sent: Monday, March 24, 2014 4:49 PM
>> To: Thiago Macieira; interest at 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
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140324/c7a013dd/attachment.html>