Hans Boehm writes:
> I think the official Thread.yield() spec curently states:
>
> Causes the currently executing thread object to temporarily pause and
allow
> other threads to execute.
>
I can't help but ask if the following is a legal transformation:
thread.yield();
==>
try {
thread.sleep(Long.MAX_VALUE);
}
catch (InterruptedException ex) {
thread.interrupt();
}
How long is a temporary pause?
----- Original Message -----
From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'Bill Pugh'" <pugh@cs.umd.edu>
Cc: <javamemorymodel@cs.umd.edu>
Sent: Tuesday, January 08, 2002 1:29 PM
Subject: RE: JavaMemoryModel: Semantics for yield and sleep
>
> 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
-------------------------------
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