> >1. single RB before WB after
> >2. monitor-style RB before, WB after RB before, WB after
> >3. double RB before, RB after WB before, WB after
> >
> >The current spec seems to allow choice (1).
>
> It isn't as simple as that. For example, if you read a volatile
> variable, then write a different volatile variable, using (1) would
> give you:
>
> RB
> read x
> write y
> WB
>
> But this would allow another thread to see the write of y before the
> read of x, which must not be allowed to happen. In particular, if x
> and y are volatile and initially 0, then if I run:
>
> Thread 1 Thread 2
> a = x b = y
> y = 1 x = 1
>
> this code must not be able to produce a = b = 1. But using (1), it could.
OK, I get this -- choice (1) is out. One more consideration though:
Reads and writes to double and long volatiles are required to be
atomic, which entails locks on some platforms. In which case it would
be nice if the memory properties were satisfied by the use of a
private lock; i.e., again arguing for monitor-style rule (2). (On
other machines, for example sparcs, atomicity can be arranged merely
by ensuring proper alignment).
When dealing solely with volatiles, I think that (2) and (3) always
have the same effect. For example:
(2) monitor-style:
RB RB
a = x b = y
WB WB *
RB RB *
y = 1 x = 1
WB WB
(3) double-barrier:
RB RB
a = x b = y
RB RB *
WB WB *
y = 1 x = 1
WB WB
These differ only in the order of (*)'ed lines, which cannot matter
here. (In fact, in both cases, the unneeded barrier seems easy to
eliminate.)
So the choice among these mainly surrounds interaction with
nonvolatiles and with locks. I'm still having trouble finding a case
where there is a compelling story to make for either choice here,
which continues to make me prefer monitor-style, just out of
simplicity of both the rules and implementation.
Sorry for dwelling on barriers rather than models here, but it seems
to be the easiest way to think about rules surrounding volatiles. I
understand that these choices also interact with code motion, but this
doesn't seem to directly impact things. Or does it?
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:21 EDT