Jeremy,
Sorry I gave you a bad example. In that example r2 was always true.
What I meant was this:
boolean step1 = false;
volatile boolean step2 = step3 = false;
Thread 1:
{
step1 = true;
step2 = true;
step3 = true;
}
Thread 2:
{
r2 = step2;
r3 = step3;
if(r3 == true)
{
r1 = step1;
// at this point, r1 and r3 are always true,
// but r2 may not be true. Even though step2 is a volatile
// that's been assigned before step3.
}
}
There might exist more realistic idioms that rely on the sequence of the
writes on several flags.
Maybe SC is too expensive to implement, but I think we should at least
require a volatile write (release) to commit all previous volatile writes
together with the previous normal writes so that a volatile flag doesn't
have a less relaxed semantics than normal flag in this regard.
Jason Yue Yang
Firmware Engineer
Enterasys Networks
Phone: 801-887-9833
-----Original Message-----
From: Jeremy Manson [mailto:jmanson@cs.umd.edu]
Sent: Thursday, March 21, 2002 12:18 PM
To: javamemorymodel@cs.umd.edu
Subject: JavaMemoryModel: SC or Coherence for Volatiles?
Well, the intent is different. We don't have SC, as that would be bad. It
is not only difficult to implement, on some platforms it is actually
impossible, apparently. And no one came up with any realistic examples
where it mattered in a program.
We do, in fact, guarantee coherence. Let's take Yue's case:
boolean complete_step1 = false;
volatile boolean complete_step2 = complete_step3 = false;
Thread 1:
{
complete_step1 = true;
complete_step2 = true;
complete_step3 = true;
}
Thread 2:
{
if(complete_step3 == true) {
r1 = complete_step1;
r2 = complete_step2;
// at this point, r1 is always true,
// but r2 may not be true.
}
}
I'm not entriely sure why he thinks that r1 is always true but r2 may not
be true. Here's what it looks like when we run it through the model
meat grinder:
Thread 1:
1: initWrite cs1 = true;
2: performWrite cs1 = true;
3: initVolatileWrite cs2 = true;
4: performVolatileWrite cs2 = true;
5: initVolatileWrite cs3 = true;
6: performVolatileWrite cs3 = true;
Thread 2
if readVolatile cs3 returns true
r1 = readNormal cs1
r2 = readVolatile cs2
Our model is a global system that atomically executes one operation from
one thread in each step. The only possible difference is that initWrites
(but not initVolatileWrites) can be moved to an earlier point in the
thread. Since this cannot happen here (the only initWrite is at the
beginning of thread 1 already), any possible execution will be a total
order over the instructions as I wrote them above.
There is no possible combination of instructions that is a total order
that results in the write to cs2 not being visible after a read from cs3
returns true. To achieve this effect, you have to reorder the writes to
the volatiles. That is not something our semantics do.
> If a single thread, say T1, writes more than one volatile field, say VA
and
> VB, in that order, I think all other threads should be required to see
> those in that order. That is:
>
> volatiles VA and VB; initially VA = VB = 0;
>
> T1:
> {
> VA = 1;
> VB = 1;
> }
>
> T2:
> {
> if (VB == 1) {
> int x = VA;
> }
> }
>
> I would say that it is _desired_ that x == 1.
>
> However, if Ta writes VA and Tb writes VB, with no other connection
between
> those writes, then other threads may observes the writes in either
> order. Put another way, in T1, the write of VA must be complete,
throughout
> the system, before the write to VB starts. However, if two writes to
> different variables are _concurrent_, then they may be perceived in
> different orders by different observers. To get ordering, you have to
touch
> something _in common_.
This is also the case. But that is only if Ta and Tb aren't the same
thread.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:38 EDT