Re: JavaMemoryModel: Executions I find profoundly troubling

From: Bill Pugh (pugh@cs.umd.edu)
Date: Mon Jul 28 2003 - 13:20:17 EDT


At 1:05 PM -0400 7/28/03, victor.luchangco@sun.com wrote:
>I do find Example 1 pretty strange because it's almost an
>out-of-thin-air occurence. I find Bill's argument against
>allowing "additional redundant reads of shared variables"
>quite persuasive: it's definitely not acceptable in other
>contexts.
>
>I'm less sure about Example 2, because offhand, it seems like
>a simple case of allowing reordering. (Isn't it sufficient to
>reorder Thread 1's first two statements after its last two,
>rather than Jerry's more complicated transformation?)

But you can't do that reordering unless you show that the write to
a[r1] and the read of a[0] are not aliased. Otherwise, even single
thread behavior goes badly astray.

> However,
>that example seems exactly analogous to the following example:
>
>Initially, X = 0, Y = 0, A = 1
>
> Thread 1 Thread 2
> r1 = X r3 = Y
> if (r1 == 0) X = r3
> A = 0
> r2 = A
> Y = r2
>
>But in this case, I think Sarita's model may not allow
>r1 == r2 == r3 == 1. (Is this true?)
>
>One argument about why this example should not be allowed
>but Bill's Example 2 should be allowed is because the *name*
>of the variable is the same in this example. I like this
>distinction: I'm in favor of enforcing orders between
>accesses to the same named variable but not to two different
>variables that happen to be aliased, though I'm not sure what
>all the implications are. I'm mostly in favor because the
>programmer can readily see that two statements use identical
>variables, but not that they might be aliased.
>
> Victor

One of the decisions we made, and present in all the current models,
is that the name used by a programmer to access shared memory is
irrelevant. This goes way back to the reads-kill example.

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



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