[concurrency-interest] Relativity of guarantees provided by volatile

Zhong Yu zhong.j.yu at gmail.com
Wed Aug 22 13:00:06 EDT 2012


On Wed, Aug 22, 2012 at 8:24 AM, Marko Topolnik <mtopolnik at inge-mark.hr> 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 have thought about this approach more carefully and the funny thing is, it still guarantees nothing. Please consider the following happens-before graph:
>
>
>     Thread R                                  /--> Rr0 --> Rr1
>                                   -----------+--------/
>                                 /            |
>     Thread W        --> Rw0 -> Ww0 ---> Rw1 -+--> Ww1
>                   /                /  ------/
>                  |                | /
>     Thread T    Wt0 -----------> Wt1
>
>
> We have the Timer thread T, which writes the volatile variable "currentTime". Both threads R and W read that var. The rest is the same as in the opening post: W writes sharedVar, R reads sharedVar.
>
> Analysis:
>
> - T writes to currentTime with actions Wt0 and Wt1;
>
> - W observes action Wt0 with the action Rw0;
>
> - W writes to sharedVar with the action Ww0;
>
> - W observes Wt1 with the action Rw1;
>
> - R observes Wt1 with the action Rr0;
>
> - R observes Ww0 with the action Rr1.
>
> Conclusions:
>
> - R first observes Wt1, then Ww0;
>
> - W first commits Ww0, then observes Wt1.
>
>
> Since there are no cycles in the graph, there is no contradiction.

Suppose W writes v=1, then observes t=1; R observes t=2, then read v.
The last read cannot see v=0.

Therefore if R/W actions are sandwiched with reading the timing
variable, we will not detect any apparent timing paradoxes.

Since we are not talking about physical time (beyond JMM) any more,
instead just a variable (within JMM), JMM guarantees that any
execution of the program appears to be sequentially consistent.


More information about the Concurrency-interest mailing list