Re: [cp-patches] Implementing Thread.sleep() via Thread.wait()

[Archie Cobbs]

Mark Wielaard wrote:
> >         * NEWS, java/lang/Thread.java, vm/reference/java/lang/VMThread.java:
> >         treat Thread.sleep(0) like Thread.yield() for JDK compatibility,
> >         and add a non-native implementation of VMThread.sleep().
>
> Could you try to follow the "Documenting what changed when with
> ChangeLog entries" section in the GNU Classpath hacker guide
> http://www.gnu.org/software/classpath/docs/hacking.html#SEC9
> That makes the entries look more the same and makes it easier to quickly
> grep for specific methods and class changes.
> I'll send an example in my next email.

Thanks, I'll fix that.

> Maybe you could explain to the person that controls this that you send
> email to public mailinglists which are read by an unknown number of
> people. And ask that it is not added automatically for such outgoing
> email. Or that people can add a flag to their headers indicating which
> emails are and which aren't "confidential" so that the text is only
> added to relevant emails.

Sure thing. It never hurts to ask.

> > Because that's what the JDK does.
>
> As explained that isn't a real argument. We would have to install and
> check all kinds of jdks to confirm this. And since a lot of them (at
> least those from sun, ibm, bea, etc) are proprietary that isn't really
> an option.

To everyone on the list: please come to agreement about whether
Thread.sleep(0) should throw InterruptedException or just be
equivalent to Thread.yield() (personally, I'm happy either way).
Then I will make the changes as necessary.

> > E.g., watch the output of this program:
> >
> > public class zz extends Thread {
> >
> >         private final int num;
> >
> >         public zz(int num) {
> >                 this.num = num;
> >         }
> >
> >         public void run() {
> >             try {
> >                 System.out.println("thread " + num);
> >                 Thread.sleep(0);
> >                 System.out.println("thread " + num);
> >                 Thread.sleep(0);
> >                 System.out.println("thread " + num);
> >                 Thread.sleep(0);
> >             } catch (Exception e) {
> >                 throw new RuntimeException(e);
> >             }
> >         }
> >
> >         public static void main(String[] args) throws Exception {
> >                 new zz(1).start();
> >                 new zz(2).start();
> >                 new zz(3).start();
> >         }
> > }
>
> Could you send the expected and actual output of the jdk you are using?

There is no "expected" output because it's a nondeterministic program.

I'm just using this program as empirical evidence (but not proof) that
the JDK treats Thread.sleep(0) as a yield. On my 1 CPU machine, this is
the output:

thread 1
thread 2
thread 3
thread 1
thread 2
thread 3
thread 1
thread 2
thread 3

If you comment out the Thread.sleep()'s, then you get this:

thread 1
thread 1
thread 1
thread 2
thread 2
thread 2
thread 3
thread 3
thread 3

These results are consistent with, and highly suggestive of, the theory
that the VM is treating Thread.sleep(0) like Thread.yield().

> It is just that I find the particular interpretation of Thread.sleep(0)
> calls Thread.yield() suspicious since Thread.yield() isn't even
> guaranteed to change control to any particular other thread. And with
> SMP systems even then you aren't guaranteed to one or another particular
> thread makes or doesn't make progress before another thread.

Right. By the same argument, there is nothing incompatible about a VM
callling Thread.yield() after every instruction execution. The only thing
really at issue here from the point of view of "spec correctness" is
whether Thread.sleep(0) can throw InterruptedException.

> Your argument is that some programs might depend on sleep(0) to act like
> yield() to escape from tight loops? Are there actually such programs.
> And wouldn't you just consider them buggy? I would.

I'm not arguing anything like that. I'm just saying: all things being
equal, behaving more consistently with the JDK (unfortunately, our current
de facto standard) is preferable.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com