Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-09-30 06:20:38

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

* 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at