**Next message:**Sarita Adve: "RE: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Previous message:**Bill Pugh: "Re: JavaMemoryModel: Spec on on wait and interrupts"**In reply to:**Sarita Adve: "RE: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Next in thread:**Sarita Adve: "RE: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Reply:**Sarita Adve: "RE: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Reply:**Bill Pugh: "Re: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

More on competing writes:

*> > Initially, X == 0
*

*> >
*

*> > Thread 1 Thread 2
*

*> >
*

*> > X = 1 X = 2
*

*> > X = 3 r2 = X
*

*> > r1 = X
*

*> >
*

*> > What values may each of r1 and r2 get? Or more to the point, what
*

*> > "special write" replaces "X = 2" so that we cannot get r1 == 1?
*

*>
*

*> I don't think there will be an argument that this should happen. So the fix:
*

*> a race write obliterates any values previously deposited by its own thread.
*

*> (Since we have SC semantics, "previous" is well-defined.)
*

This fix doesn't quite work. Consider, for example, the following:

Initially, X == 0, V == 0 (V is volatile)

Thread 1 Thread 2 Thread 3

X = 1 X = 2 while (V == 0) {}

V = 1 r2 = X X = 3

r1 = X

Can we get r1 == 1?

Perhaps we should say that a write obliterates any value written by a

write that happens before it (i.e., use "previous" in the "happens

before" sense, rather than using program order or the SC execution).

I'm still not quite sure how to define this notion though, because

both "r1 = X" and "r2 = X" may see the "X = 2" write, and somehow,

we need to know that r1 cannot get 1 while r2 can. The notion we

are looking for may be close to what WW-dag consistency allows

(i.e., the "allowable writes" definition of Jeremy and Bill).

*> Of course, in the philosophy of "weaker is better," I can think of
*

*> one scenario (albeit far-fetched) where [another "strange" execution]
*

*> may actually occur, and it is unclear to me if we do want to fix it.
*

I don't know whether we should or shouldn't allow these executions.

Even when I have an opinion on the matter, I haven't thought hard

enough, nor consulted widely enough, to be confident that I have

considered all the issues. I'm even ambivalent about the "weaker

is better" philosophy (though I don't believe that we should make

the model stronger just to make debugging broken programs easier--

there are better ways to do that). That's one of the reasons I'm

glad Jeremy and Bill have looked so long and hard at these issues.

Someone ought to.

Anyway, let me know if you come up with something that resolves

the above problem, or if you think the idea of using "allowable

writes" is sufficient (assuming the details can be worked out).

Victor

-------------------------------

JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel

**Next message:**Sarita Adve: "RE: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Previous message:**Bill Pugh: "Re: JavaMemoryModel: Spec on on wait and interrupts"**In reply to:**Sarita Adve: "RE: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Next in thread:**Sarita Adve: "RE: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Reply:**Sarita Adve: "RE: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Reply:**Bill Pugh: "Re: JavaMemoryModel: The Intuition Is the Model - the full model is in this email!"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

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