[concurrency-interest] Relativity of guarantees provided by volatile
zhong.j.yu at gmail.com
Tue Aug 21 17:33:14 EDT 2012
On Tue, Aug 21, 2012 at 2:13 PM, Marko Topolnik <mtopolnik at inge-mark.hr> wrote:
> On 21. kol. 2012., at 20:03, Boehm, Hans wrote:
>>> Let's say that they could in theory be reflecting the exact time. We
>>> don't have to descend into the gory details of specific CPUs. Imagine a
>>> CPU specifically built to allow precise wall-clock time observation.
>> Then I think it depends on how the CPU makes that time available to clients.
>> If it does it in a way that's equivalent to regularly updating a volatile
>> variable that can be read by all threads, then timing should work as expected.
>> I think the current specification for the timing functions is effectively
>> much weaker, because it's silent on the issues.
>> I think that if we agree this is a problem, then it could be fixed by
>> updating the specifications for the timing functions, without touching the
>> memory model per se. I'm not sure I understand the implementation
>> implications of that, so I'm neither advocating it, nor lobbying against it.
>> The C++ specification is somewhere in the middle, and I remain a bit nervous
>> about implementability there.
> I feel that this issue is not about actually calling any timing functions, but about the expectations on the timeliness of the visibility of volatile writes. Currently the programmer is left with a very vague and uncertain "general expectation" that volatile writes will be made visible "as soon as possible".
Similar to your concern that consecutive volatile writes can be
compressed into the last write, it also seems true that consecutive
volatile reads can be compressed into the first read - exactly the
kind of optimization to be disabled by C's volatile. It's
inconceivable that any JVM will do such optimization on volatile
reads, it'll break lots of programs, e.g. busy waits.
Two reasonable physical constraints can prevent these oddities:
1. every synchronization action takes non-zero time.
2. upper limit on discrepancy between synchronization order and
temporal order: if A is before B in synchronization order, A cannot be
indefinitely later than B, A must occur before (B.time + T) where T is
the upper limit.
More information about the Concurrency-interest