Re: JavaMemoryModel: SC or Coherence for Volatiles?

From: Jeremy Manson (
Date: Mon Mar 25 2002 - 16:12:06 EST

> 1) Why must volatile writes be divided in more than one stage to allow
> Figure 13 in your paper to happen? As detailed in message
>, that =
> seems
> to be a legal trace under your simple semantics.

That's a typo in the paper. Thank you for spotting it; I'll fix it. It
will become identical to the first example in

> 2) In initVolatileWrite, should it read
> "Assert uncommittedVolatileValue_v = n/a"
> instead of "!= n/a"? Don't you want to block a concurrent
> initVolatileWrite on the same v?

What we were trying to get at with that is that when you start the
initVolatileWrite, that uncommittedVolatileValue_v should be n/a. Once we
have asserted that, we promptly change uncommittedVolatileValue_v. This
has the effect that if some initVolatileWrite a has started changing a
variable v, no other initVolatileWrite b can start changing v until the
corresponding performVolatileWrite for a has occurred.

> 3) What is readThisVolatile used for?

Another typo. I'm glad that there are people willing to bang on this a
little, so I thank you again. readThisVolatile_t_<w,info_t> should be set
to true in the "else" section of readVolatile. This prevents any thread
that has seen the uncommitted value of a volatile from reversing itself
and seeing the previous value.

> 4) Are you really trying to achieve the relaxation that "there is only a
> total order over writes to individual volatile variables" proposed in
> Section 8.6.1? Or is the intention somewhat different?

> For example, are you going to allow the following?
> Initially,
> volatile int a = 0;
> volatile int b = 0;
> T1:
> a = 1;
> u = b;
> T2:
> b = 1;
> v = a;
> Can (u, v) = (0, 0)? (Which should be allowed by the relaxation you
> proposed in Section 8.6.1.)

8.6.1 is really more of a motivational section. This behavior is not
allowed, and I should probably remove that line if it is causing

I hope this helps.

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:39 EDT