O�Reilly threads e.g

[faiza haris]

The e.g is from O�reilly Threads chap.
It should print foo and bar alternately on time-slicing win98 system.
However i am getting lots of foo, then alternate foo, bar and then lots of bar printed, alternate, repeat frm foo.
I cannot explain this behaviour...so can someone explain?

class Testthreadscheduling{
public static void main(String args[]){
new MyThread("foo").start();
new MyThread("bar").start();

// Thread bar = new MyThread("Bar");
// bar.setPriority(Thread.NORM_PRIORITY + 1);
//bar.start();
}
}
class MyThread extends Thread{
String message;
MyThread(String message){
this.message = message;
}
public void run(){
while (true)
{
System.out.println(message);
// yield();
}
}
}

[Tanveer Rameez]

In an ideal time-slicing OS, since both the threads have equals priority , they should give same no. of foo and bar alternately. But how the OS handles threading,scheduling & time-slicing differs from OS to OS. So if it solely upto how the OS implements threading & time-slicing.WE cannot predict accuraelty how things in threading specially the execution order will occur .Even at different times in the same machine the output may vary.
WEll, when I tried out in my windows NT, it gave me about a ten foo folloewd by 10 bars and so on. there is no alternate foo and bar.Then on the second run, I got more foo than bar.

[gautham kasinath]

Hi!
Well I am experienceing the same problem I guess it has to do with the priority that the system allots for internal threads and our threads.. i ll try to find a way to sync. them..
Regds
Gautham Kasinath

[Michael Ernest]

I don't really see a problem in the way the program is running. But the assumption that "foo" and "bar" should execute alternately would not be a proper inference of time-slicing. That behavior would be an example of something like "instruction interleaving."
You have a very simple loop that executes one statement repeatedly. This is instantiated twice, with different String values, and then each is started.
One Thread is executing as many times as it can before it is kicked out of the CPU. Since the run() is nearly atomic, the runnning thread executes multiple times before the next Thread is scheduled and run. So there is a time-slicing behavior in effect -- just not at the level of one method call.
-----------------
Michael Ernest, co-author of:
The Complete Java 2 Certification Study Guide
[This message has been edited by Michael Ernest (edited December 26, 2000).]

[mohit joshi]

And since the speed of processors is increasing very fast, it is possible that three years back, on an 486 machine, this program will print foo and bar only once.
I got a similar problem while testing the repaint - update - paint theory of RHE. RHE claims that even if the fastest Kangaroo in the world jumps on the button and repaint gets executed 50 times a second, the paint method will not be called more then 10 times in a second. I wrote a program which continuously calls repaint and found that the paint method also gets executed 100s of time in a second.
I think this unexpected behaviour is because of faster processors ( compared to the time the api was written ) and because the api doesnt take this into account.