[Fwd: Re: JavaMemoryModel: Questions about the proposed semantics]

From: Alex Gontmakher (gsasha@cs.technion.ac.il)
Date: Wed May 09 2001 - 23:21:32 EDT


> > Date: Fri, 01 Sep 2000 13:32:14 -0700
> ^^^ As a side note, you should probably look into that. I'm pretty sure
> that isn't today's date.

Thanks. Fixed.

> > ------------------------------------------------------------------------
> >
> > Consider the following executions:
> >
> > Execution 1 Execution 2
> > 1. x=1 1. x==1
> > //------------- no barriers //---------------- no barriers
> > 2. x=2 2. x=2
> > 3. x==1 3. x==1
> >
> > Execution 1 is not permitted by the model. Execution 2 is permitted.
>
> What are these executions of? Are these taking place in multiple threads?
> I'm not sure why you think Execution 1 is somehow not permitted and
> Execution 2 is. It the == operation supposed to test equality and return
> true or false? If so, then this is just a few lines of code: what would
> prevent them from being executed?

The == operation means just "A read from x that returns 1". Sorry if
this
notation is confusing... I'll try not to use it any more.

These are two different executions (actually, parts of executions. In
Execution
2, the value 1 may be written to x by some thread not shown here).

The conclusion that the first execution is forbidden and the second one
is
permitted, follows from my understanding of the new definition of
semantics in
Bill Pugh's paper.
In Ex1, the operation 2 removes the result of op. 1 from the set of
visible
writes. In Ex.2, it does not (necessarily), since the value can be
written in
another thread. Therefore, in Ex.1, the value 1 is not visible to
operation 3,
while in Ex. 2 it is.

> As a side note, there is no reason to expect a compiler not to unroll the
> loop once, and then eliminate the k = i inside the loop so that it only
> gets executed once. A compiler could also register-allocate i, so it
> never is seen to change. To a programmer who hasn't "gotten the message",
> this behavior might be just as surprising as non-monotonicity. But we
> wouldn't think about making those optimizations illegal.

Still, you can see that you cannot provide a likely scenario that would
make the
sequence of k's be non-monotonic. All I wanted to say is "hey, a
programmer can
think this and DO THIS" (I do not claim *I* would do this). So, this
point
should be clear in the spec of the language (either way - just be
explicit about
it), otherwise you'll see people doing things like that, and then, OUCH:
you
have a spec and programs that violate it, which I think, is a bad thing
by
itself, even if the program remains correct for the while being.

> Our proposed spec (and all of the others) doesn't discuss aliasing, and
> just deals with the memory model on the level of memory accesses. Aliasing
> is a syntactic issue, as you say: our spec deals (almost exclusively) with
> the JVM, not the Java language.

I admit I do not really understand it. Isn't it the programmer who has
to write
the (correct) multithreaded programs? What good is the (supposedly
multithreaded) language to the programmer if its memory semantics are
not
specified?

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



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