I would like to point out that based on Bill's proposal so far, volatiles
cannot be treated as one-way barriers (for non-volatile accesses), leave
alone as two-way barriers. Let me specify the tradeoffs here a little
differently from what Bill said in his last message.
I think we have to make a fundamental choice between whether we would like
programmers to think about the memory model in terms of per-thread
orderings, or if we are ok with thinking in terms of inter-thread orderings.
Per-thread ordering based specification:
-----------------------------------------
Pros: Easy to specify. (For some, this may be interpreted as easy to reason
with.)
Cons: With models specified purely in terms of per-thread orderings, it will
be difficult, if not impossible, to allow optimizations like "eliminate
thread-local volatiles" (which Bill has proposed to be desirable) and to
allow systems like lazy release consistent software DSMs. There are other
subtle write atomicity related optimizations that we haven't discussed fully
yet.
Inter-thread ordering based specification:
-------------------------------------------
Pros: Can capture more optimizations and systems than per-thread based.
Cons: Almost any specification to capture non-data-race-free programs (i.e.,
non-sequentially consistent behavior) will be more involved and less
intuitive. Note that for "data-race-free" programs, we have an intuitive
spec (system will appear sequentially consistent).
What does this have to do with one-way vs. two-way barrier semantics?
---------------------------------------------------------------------
If we choose to use per-thread spec, I see the merit in having volatiles
specified as two-way barriers from a programmability perspective.
But if we choose to use inter-thread spec (Bill's current proposal),
volatiles can neither be interpreted as one-way nor two-way barriers.
(Therefore, the programmability argument for two-way barriers seems moot.)
Consider:
Thread 1:
A
Initially all variables are 0
Thread 1
A = 1
Volatile1 = 2
tmp1 = Volatile2
B = 1
Thread 2
while (B != 1) {;}
Volatile3 = 3
tmp2 = Volatile4
tmp3 = A
Treating a volatile as a barrier with respect to normal accesses (either one
way or two way) means that tmp3 should be 1. This is not enforced by Bill's
proposal so far. If we were to enforce this, we would not be able to remove
thread-local volatiles (as Bill has proposed to be a desired optimization)
or allow lazy release consistent software DSMs.
The above example shows that treating volatiles as barriers means that you
are allowing communication between threads through non-volatile/non-synch
variables (B, in the above example). As Bill said, it isn't clear to me that
this is good programming practice. Again, this is irrespective of whether
you think of the barrier as one-way or two-way; it is thinking about it as a
barrier at all that causes the problem.
If volatiles aren't barriers, what are they?
--------------------------------------------
Instead of thinking about volatiles as barriers for normal (non-volatile)
accesses, think of them as accesses used for communication of normal
locations between two threads. A volatile write is a sender of previous
normal values of its processor and a volatile read is a receiver for
subsequent normal accesses of its processor.
Some codes may want to use a read volatile to send normal values and a write
to receive values - this is what people have been calling two-way barriers -
but viewed in this way, it isn't very intuitive for a write to recieve and
read to send information.
Sarita
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT