[concurrency-interest] Fences API and visibility/coherency

[Dmitriy V'jukov]

On Tue, Oct 13, 2009 at 8:44 AM, David Holmes <davidcholmes at aapt.net.au> wrote:
>
> Taking one last stab at clearing this up ...
>
> Dmitriy V'jukov writes:
>> My question basically boils down to: if thread 1 periodically calls
>> VolatileValue.getX(), and we know by wall clock that thread 2 executed
>> VolatileValue.setX(), let's say, an hour ago, is there any guarantees
>> that thread 1 will eventually see 42?
>
> Of course. The first getX() that occurs after setX() will return 42.


Definitely. I agree with you. But the problem that "getX() that occurs
after setX()" may never occur. It's not wall-clock time, right?
"After" is defined by "synchronization-order", and
synchronization-order does not care about wall-clock time. So where
are any guarantees that "getX() that occurs after setX()" will ever
occur?


>> Then, if we will replace volatile by plain var + Fences, what about
>> guarantees then?
>
> Assuming the correct Fence method is used - I believe so. The Fences API defines additional happens-before relationships and that will ensure visibility and ordering.

Happens-before is not about visibility in any way, shape or form. It
basically guarantees that if/when you've seen X, then you will see
everything that happened before X. It's just ordering. It does not
guarantee that you will see X itself, and when you will see X.
And what I am talking about is that you may not see X. Ever. So the
guarantee that "if you will see X, then..." totally does not matter,
because it's not guaranteed that you will see X itself.



>
> (How this happens is another matter - one of the contention points with the Fences API is that it isn't always obvious which actions need to be handled specially because of a use of the Fences API elsewhere. And I'm not an expert on the Fences API - personally I think its not a good idea.)
>
>> Happens-before has nothing to do with this. Because it's
>> happens-before that will be determined by the synchronizes-with
>> relation, and not vise versa. Coherence is a kind of primary thing
>> here, and ordering is secondary, sort of.
>
> I do not understand why you keep saying things like this - obviously there is some fundamental disconnect here (and I'm not sure what you are meaning by coherence in this context).

Propagation of changes. Like in "cache coherent system".
If we have variable, and one thread writes to it, the changes have to
propagate to other threads.


> The happens-before ordering is defined by JLS 17.4.5. If there is a happens-before relationship between a write of a variable and a subsequent read of that variable, then the read must return the value written.

There is no happens-before relation between volatile write and
volatile read in my examples.
If you disagree, please prove opposite - you need to prove that read
occurs after write, after as defined by synchronization order, so you
need to prove that so(read, write).
If the things as you said, the proof must exist, right?

My proof is as follows:
There is no happens-before relation between volatile store and
volatile load. So the load always allowed to return initial value of
the variable.


> A happens-before relationship can come about in a number of ways including:
> a) the variable concerned is volatile
> b) the write and read occur within synchronized regions of code that lock the same monitor
>
> and now,
>
> c) the Fences API has been correctly used to introduce a happens-before relationship.
>
> The implementation is responsible for ensuring the memory model is obeyed. So for example, a simple implementation could always write a volatile variable to memory and add whatever platform specific memory synchronization instruction is needed. A hypothetical, sophisticated/complex implementation might only write variables into thread-local locations initially and upon a read of the variable deduce if a happens-before ordering exists that requires that the variable's value be retrieved from one of those thread-local locations.
>
>> Thank you. I will ask my question there. I was just not aware of that
>> mailing, and seen here some discussions of Fences API.
>
> Sure. Discussing Fences API on either list is fine - but if there are issues to reconcile concerning the JMM fundamentals it's probably best to do that on the JMM list first.

Here is my question on javamemorymodel-discussion list (archives
available only for members):
https://mailman.cs.umd.edu/mailman/private/javamemorymodel-discussion/2009-October/000357.html


-- 
Dmitry Vyukov