[concurrency-interest] Relativity of guarantees provided by volatile
mtopolnik at inge-mark.hr
Wed Aug 22 09:24:16 EDT 2012
>> 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.
- 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.
- 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.
More information about the Concurrency-interest