Alexander Terekhov wrote:
Peter Dimov wrote:
Alexander Terekhov wrote:
I mean that current expired() doesn't synchronize the local view of counter and hence may never return true (absent some user's synchronization).
On which platform?
Ok. Insert "in theory".
Hm. I thought that we were discussing the platform-specific implementation. It seems that you are on a higher level: bool expired() { return !lock(); } I don't think that this is an improvement. The user that wants !lock() writes !lock(). The user that wants a (potentially more efficient version of - insert "in theory" here as well) use_count() == 0 writes expired(). It is deliberately "unspecified" whether expired() msyncs or not. Most expired()-based code isn't thread safe regardless of msync.
It's PDQ in practice (unless you have a compiler smart enough to ignore volatile hack and use a cached copy in spite of it because you're not supposed to noticed the difference according to the MT memory model rules).
You need to insert lots of "in theory" here. * "volatile" is specifically intended to prevent "smartness". In theory, a company may have a customer base that uses "volatile" incorrectly left, right and center, and then complains about the compiler not being smart enough. * the variable may be in uncached, memory-mapped I/O space. * the virtual address may be unmapped and generate a trap. * the CPU may have set a hardware breakpoint at the address. * the user may be running a debugger and poking with the variable. * an asynchronous event (signal, interrupt) may be updating the variable. And so on. Even if we discount all of these observers of the abstract machine, there is also the point that if the compiler really knows that eliminating the access is undetectable, then it is undetectable, i.e. the code will work as "well" as before (only the probability of error may increase).