I think the official Thread.yield() spec curently states:
Causes the currently executing thread object to temporarily pause and allow
other threads to execute.
The problem is that the other threads may presuambly be system threads, and
thus there may not be visible progress. In fact gcj, for example,
implements this with sched_yield() which, at least on Linux, can yield to
another process entirely. (I'm not sure what else it could reasonably do on
Linux.) I suspect the standard VMs do something similar. Cliff? Thus I'm
not at all sure that even standard VMs currently satisfy the stronger
semantics, unless you're very careful to define what you mean by
"probability".
My intuition is that the current spec has roughly the right level of
ambiguity, and it would be nice to avoid changing it. If we have to say
something specific, I would say that we are not prohibiting the
transformations you describe, though they are strongly discouraged, and may
(or may not) be prohibited by other parts of the Java specification.
Hans
> -----Original Message-----
> From: Bill Pugh [mailto:pugh@cs.umd.edu]
> Sent: Friday, January 04, 2002 8:41 AM
> To: Jerry Schwarz; javamemorymodel@cs.umd.edu
> 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