> > Initially A=B=C=D=0
> > Thread 1
> > A = 1
> > B = 1
> >
> > Thread 2
> > A = 2
> > C = 1
> >
> > Thread 3
> > while (B! = 1) {;}
> > while (C != 1) {;}
> > register1 = A
> >
> > Thread 4
> > while (B != 1) {;}
> > while (C != 1) {;}
> > register2 = A
> >
> > Result: register1 = 1, register2 = 2
> The code sample looks like the kind of thing a novice armed with the
> knowledge of volatile would try to write.
I'm still trying hard and failing to picture this.
Threads 1&2 could be interleaved in any order anyway, for example
A = 2; A = 1; B = 1; C = 1;
A = 1; B = 1; A = 2; C = 1;
etc
So no program could depend on reader threads (3&4) seeing A as 1 vs 2.
The issue here is whether anyone would depend, without any further
coordination, on both threads seeing the SAME value for A, without
knowing which value that might be.
The only situations in which I've ever encountered anything vaguely
like this are in some fault-tolerant distributed multicast/consensus
protocols. These don't have any obvious analogs with concurrent
programming on multiprocessors. And even if they did, anyone building
them would coordinate via locks etc rather than trying to get away
with this. (Especially after seeing that the spec says that there
aren't any promises about it.)
It's worth stressing the esotericness of this issue. We need to give
any answer about its semantics, even though the answer at most impacts
weird hacks. Simple uses of volatile stay simple.
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/ ------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:34 EDT