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