[concurrency-interest] Relativity of guarantees provided by volatile

Marko Topolnik mtopolnik at inge-mark.hr
Tue Aug 21 15:13:16 EDT 2012


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". It reminds me of the contract for Runtime.gc(). 


More information about the Concurrency-interest mailing list