Bill Pugh writes:
> ... the alternative is to say that it is perfectly legal (although
> undesirable) for a compiler or JVM to perform the following
> transformations:
Whether a "compiler" can perform this transformation,
I agree that these transformations are legal under (non)existing semantics
*if* you're talking about a runtime compiler that has intimate knowledge of
the JVM's "best effort" when it comes to Thread.yield().
But I would not consider this to be a legal transformation for javac.
----- Original Message -----
From: "Bill Pugh" <pugh@cs.umd.edu>
To: "Jerry Schwarz" <jschwarz@us.oracle.com>; <javamemorymodel@cs.umd.edu>
Sent: Friday, January 04, 2002 8:40 AM
Subject: Re: JavaMemoryModel: Semantics for yield and sleep
At 11:31 AM -0800 1/3/02, Jerry Schwarz wrote:
>
>We have a VM for which we don't expect people to write multithreaded
>applications. Threads are can be used to deal with blocking I/O and
>co-routining, but it is not intended to be used for long running
>parrallel threads requiring scheduling.
OK. Since some people are opposed to the semantics I suggest, the
alternative is to say that it is perfectly legal (although
undesirable) for a compiler or JVM to perform the following
transformations:
---------------------
Example 1:
Initially, volatile x = 0
Thread 1:
while (x == 0) {
Thread.yield();
}
Thread 2:
x = 1
can be transformed to -->
Initially, volatile x = 0
Thread 1:
int r1 = x;
while (r1 == 0) {}
Thread 2:
x = 1
---------------------
Example 2:
Initially, x = 0 (x is non-volatile in this example).
Thread 1:
int r1;
do {
Thread.yield();
synchronized(this) {
r1 = x;
}
} while (r1 == 0);
Thread 2:
synchronized(this) {
x = 1
}
can be transformed to -->
Initially, x = 0 (x is non-volatile in this example).
Thread 1:
int r1;
synchronized(this) {
r1 = x;
do { } while (r1== 0);
}
Thread 2:
synchronized(this) {
x = 1
}
-----------------
I don't know of any other acceptable way to prohibit such transformations.
And I don't like the idea of having a semantics that allows these
transformations, but not clearly spelling out the implications of the
semantics. If the semantics allows these transformations, the
description of the semantics should clearly state so.
So, are people happier with the idea of having the semantics clearly
state that these transformations are legal but undesirable from a
quality of service point of view?
Bill
-------------------------------
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:37 EDT