Conference abbott::java

The project team  putting out our JDK is headed by someone called
Will Kling.  Try approaching him with this. Bill Mckeeman is another
name to try if you can't get hold of Will.

I also believe that we're due to ship our own JIT for Digital UNIX
somewhere in the March time frame.  Maybe this implementation will
address the points you've raised. 

Best of luck ..

John
[Posted by WWW Notes gateway]

> 1) The threading mechanism is non-preemptive.

IMHO, this is among the worst problems with most JVMs wrt servers.  
My workaround is to just stick a sleep() into every thread's loop.

I understand that this problem stems from the fact that most
Unix implementations don't have reentrent semaphores (something
that Java depends upon) so Sun decided to use "Green threads"
instead of the native threads implementation.

More fallout from this is that java threads only run on one
processor per JVM.

It may be that our java port will use native threads?

    
    sleep() or maybe yield()
    
    The OSF's JDK port does pre-emption - has the Digital version
    regressed? (I don't have DUNIX 4.0, so can't check).
    
    My understanding is that *all* implementations are pre-emptive, but some
    are not time-sliced (ie a high priority thread will always pre-empt a lower
    priority thread, but two threads with the same priority will not
    necessarily time-slice).  Nit picking I know, but the difference is
    important.
    
    Not very satisfactory, but did you consider the poor man's
    time-slicing, having a high priority thread that does nothing but
    wake up every second or so, thus giving the VM a chance to schedule
    another thread?
    
    
    	/Damian
    
    

>    sleep() or maybe yield()

I haven't researched this to be sure, but I understand that
yield() doesn't /have/ to give up control if the scheduler decides
in the yield() call that it doesn't need to (no higher priority
threads ready).


Actually, I'm a little annoyed at Sun for not rigorously defining
the thread scheduling model.  Hopefully that will come later.

    
    JDK 1.1 indicates that a thread will yield to another runnable
    thread when it calls yield() - so it *should* work.
    
    FWIW, could someone with DUNIX 4.0 and the Digital version of the JDK
    try the following out?  The higher priority thread should pre-empt the
    lower priority thread.  If it doesn't then I sincerely hope things get
    better with the JDK 1.1 port.
    
    import java.io.*;
    
    class test {
        public static void main(String[] args) {
          Thread low = new Thread(new LowThread());
          Thread high = new Thread(new HighThread());
    
          high.setPriority(Thread.NORM_PRIORITY + 1);
          high.start();
          low.start();
        }
    }
    
    class LowThread implements Runnable {
        public void run() {
          System.out.println("Low Started");
          for(int i = 0; i < 100000000; i++);
          System.out.println("Low finished");
        }
    }
    class HighThread implements Runnable {
        public void run() {
          System.out.println("High started, going to sleep");
          try {
              Thread.currentThread().sleep(1000);
          } catch(Exception e) {}
          System.out.println("High is Awake, and finishing");
        }
    }

Is there a good reference for thread scheduling under java?

I used Digital UNIX port a couple times, it did support preemption, 
but not timeslicing.


The only documetation I could find about yield is:

  public static void yield()

     Causes the currently executing thread object to temporarily pause 
     and allow other threads to execute. 


So, an arbitrary JVM wouldn't have to reschedule the threads if
the rest of the threads were running at a lower priority (possibly
the same priority too).  I'm guessing this because I assume the 
"other threads" might only mean higher priority threads.  It isn't
very clear.

I've found that:

yield() in the higher priority thread doesn't let the lower
priority thread run

yield() in the low priority thread allows the higher one to run
(as expected)

yield() does in fact work round-robin for same priority threads
(at least in the OSF1 and linux case)

if the low thread starts just before the high thread, the high thread
runs (I could guess why, but I'd probably be wrong)

if the low thread starts a few seconds before the high thread, the low
thread runs until the scheduler is called again (as you might expect)


There's probably more...

I poked around in Doug Lea's "Concurrent Programming in Java"
tonight; here's what I found:

(p24) The Thread.yield method relinquishes control, which may enable one 
or more other threads of equal priority to run.

(p211) [lists "sleep" and the "high priority thread shakes up the
scheduler" methods of forcing preemption.  Also says:
the Java Language Specification does not guarantee that threads 
tied for the highest priority are run fairly.

It also mentions something I missed before: 

  One of the runnable threads with the highest priority
  is alwasy chosen to run.

And they give some techniques to ensure fair secheduling.

    JDK 1.1 says yield() "Causes the currently executing Thread object to
    yield. If there are other runnable Threads they will be scheduled next. "
    
    	/Damian

When I just checked the 1.1 docs at
http://www.javasoft.com:80/products/jdk/1.1/docs/api/java.lang.Thread.html#yield
()
had what I first posted...

Interestingly, the sleep docs don't mention scheduling either.

I'm probably reading too much into this.  After all, Java is still
developing, I'm sure the docs will get sorted out to something
sane eventually.

If it helps, we expect the JDK 1.1 release to use
native threads.

It will help that JDK 1.1 uses native threads only if the rest of the VM can
take a good pounding. I would say that one way you could test your
implementation is by compiling Jigsaw, running it on a multiprocessor machine
and doing bunches of HTTP requests. If the VM falls over, then you know you
still have some work to do. Note that this is only a first level test.