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

[Mark Wielaard]

Hi,

On Fri, 2004-12-31 at 14:50 -0600, Archie Cobbs wrote:
> Mark Wielaard wrote:
> >>Good point.. I've reimplemented this in VMThread.sleep() instead.
> >>Let me know what you think.
> > 
> > Could you please supply a ChangeLog entry. that makes reviewing much
> > easier.
> 
>          * 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.

> You really think I have control over that? :-) When I send email from
> my workplace (which is behind the firewall of a large hospital) it gets
> added automatically. Please accept my apologies.

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.

> As I mentioned, the removal was inadvertent. How's this instead:
> 
> Index: NEWS
> ===================================================================
> RCS file: /cvsroot/classpath/classpath/NEWS,v
> retrieving revision 1.61
> diff -u -r1.61 NEWS
> --- NEWS        30 Dec 2004 13:18:17 -0000      1.61
> +++ NEWS        31 Dec 2004 20:47:27 -0000
> @@ -17,6 +17,9 @@
>   * VMThread.sleep() will never be called with zero arguments (don't sleep).
>     VMThread does not have to do any extra argument checking. Some (wrong)
>     documentation about the behavior of this method has been updated.
> +  Also, VMThread.sleep() now has a default non-native implementation, but
> +  it is a generic implementation that ignores the nano-seconds argument.
> +  Runtime hackers are encouraged to provide a more efficient version.

Cool. Thanks.

> >>+   * <p>
> >>+   * A zero length sleep is equivalent to <code>Thread.yield()</code>.
> > 
> > I think this is not a good idea. This is not supported by any
> > documentation. And I agree with you that it is probably a bug in the
> > implementation you tested and filed a bug report for the fact that
> > sleep(0) seems to ignore the interrupted state of the Thread. And if we
> > want to add this bug to our implementation (and I think we shouldn't)
> > why Thread.yield(), why not just return?
> 
> 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.

>  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?
I would expect the output to be nondeterministic since the scheduling
order of the threads cannot be determined. I quickly tested with gcj
(changing sleep(0) to yield() to check) and I was kind of surprized by
the fact that the output was more regular than I would expect. But I
would never rely on that and use explicit synchronization because I am
sure I would get bitten by that.

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.

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.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part