Heya,
From the following link:
http://java.sun.com/docs/books/tutor.../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
