Java Threads scheduling: Determinitic?

From: Anne (anne_dolly00_at_yahoo.co.uk)
Date: 02/29/04 

Date: 29 Feb 2004 07:27:57 -0800

Heya,

>From the following link:
http://java.sun.com/docs/books/tutorial/essential/threads/priority.html
It is said that:
<<The Java runtime supports a very simple, deterministic scheduling
algorithm known as fixed priority scheduling>>. The algorithms are
particularly deterministic!

The link includes two threads (of equal priority scheduling order)
code.
The run method for these two threads is
public void run() {
    while (tick < 400000) {
        tick++;
        if ((tick % 50000) == 0)
            System.out.println("Thread #" + num
                               + ", tick = " + tick);
    }
}
This run method contains a tight loop that increments the integer tick
and every 50,000 ticks prints out the thread's identifier and its tick
count.
In execution on a time sliced operating systems,the output might look
like:
Thread #1, tick = 50000
Thread #0, tick = 50000
Thread #0, tick = 100000
Thread #1, tick = 100000
Thread #1, tick = 150000
Thread #1, tick = 200000
Thread #0, tick = 150000
Thread #0, tick = 200000
Thread #1, tick = 250000
Thread #0, tick = 250000
Thread #0, tick = 300000
Thread #1, tick = 300000
Thread #1, tick = 350000
Thread #0, tick = 350000
Thread #0, tick = 400000
Thread #1, tick = 400000

As mentioned in the article:
<< time-sliced system divides the CPU into time slots and iteratively
gives each of the equal-and-highest priority threads a time slot in
which to run. The time-sliced system iterates through the
equal-and-highest priority threads, allowing each one a bit of time to
run, until one or more of them finishes or until a higher priority
thread preempts them.>>
Then the article went on saying:
<<Notice that time-slicing makes no guarantees as to how often or in
what order threads are scheduled to run>>, altough the article claims
(see above) that JRE supports deterministic scheduling algorithm!

Personally,I can't understand from the above program output why some
threads gets longer CPU quantum than others although they have the
same priority and instantiates the same class, thus similar (CPU, I/O)
dynamic utilisation.
Since a time sliced OS uses a same time quantum value, and the above
two threads moving through the same states [runnable, running,
blocked],I expect that each thread will have similar CPU quantums
number, and therefore the interleaving between the threads
(instantiating the same class) should be regular, i.e. N successive
CPU shots for thread1 then N successive CPU shots for thread 2, M
successive CPU shots for thread1 then M successive CPU shots for
thread 2, etc….which is not the case.
 
Is there anything i am missing? is the issue related to how the JRE
coordinates with the underlying OS? how , i really wonder?

Besides, if we run the same program, we end up with different outputs;
personally I expect only a possibe change on the threads order of
execution.

When running this program on a non-time-sliced system, however, you
will see messages from one thread finish printing before the other
thread ever gets a chance to print one message. Like this:
Thread #0, tick = 50000
Thread #0, tick = 100000
Thread #0, tick = 150000
Thread #0, tick = 200000
Thread #0, tick = 250000
Thread #0, tick = 300000
Thread #0, tick = 350000
Thread #0, tick = 400000
Thread #1, tick = 50000
Thread #1, tick = 100000
Thread #1, tick = 150000
Thread #1, tick = 200000
Thread #1, tick = 250000
Thread #1, tick = 300000
Thread #1, tick = 350000
Thread #1, tick = 400000

Does it mean that System.println() is not a blocking system call. I
was expecting the thread to move to a blocking state.

Thanks for ur help

Relevant Pages

  • Re: Lahman, how ya doing?
    ... >>>tick processing in a lower priority thread. ... >> I think I understand that in the context of the real controller. ... >> time is checked, and if a tick has passed, the low priority queue is ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... >>>done on some ticks in the real controller. ... >> I can imagine a high priority queue for analog peices whose evolution is ... and a low priority queue for delayable digital parts. ... >60 processing gets done in that tick but the 1 and 7 tick processing ...
    (comp.object)
  • Re: OEMGetRealTime and SoftRTC flag
    ... it's asking too much that there will be some default settings for ... Don't rule out that the tick count ISR is held off due to processing of an ... already running ISR. ... tick source) had the highest priority which seems no to be the case. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Need to run function every 20ms.
    ... CE is preemptive - a thread of higher priority will be scheduled if it need CPU at thenext tick or at an event which changes the run state. ... you can generate a system tick every 1mS. ...
    (microsoft.public.windowsce.embedded.vc)
  • Java Threads scheduling: Determinitic?
    ... algorithm known as fixed priority scheduling>>. ... The link includes two threads (of equal priority scheduling order) ... This run method contains a tight loop that increments the integer tick ... CPU shots for thread1 then N successive CPU shots for thread 2, ...
    (comp.os.linux.misc)