Hi Vad. I get two Lucy's or two Fred's in a row. So either it is Not guaranteed or there is a bug in the VM.
I don�t see anything in the JLS or The
Java Programming Language that dictates how the scheduler has to behave. On the subject of yield, TJPL says you can generally rely on the scheduler to �do the right thing� even though there is no specification of exactly what that is. As far as I can tell, fairness depends on the scheduling policy.
I�ve been thinking about how to explain two Lucy�s or two Fred�s in a row. The Lucy thread invokes sleep(1). Lucy is moved to another queue or some flag state flag is set so that Lucy will not be selected to run. Then the VM negotiates with the underlying OS to set a timer for 1 millisecond. That�s 1000 microseconds. Then the VM selects Fred to run. Suppose Fred invokes sleep before that 1000 microseconds expires. Now we have two sleeping threads, but Lucy�s expire time is sooner than Fred�s. The VM does not have anything to do. The OS swaps out the VM process and does other things.
A hardware interrupt occurs due to the first timer and the OS somehow conveys the interrupt to the VM. Eventually the OS swaps in the VM. The evidence shows that occasionally the VM selects Fred instead of Lucy. So Fred�s timer must also have expired. Maybe the timers are not mapped one-for-one to threads, or perhaps the granularity of OS timers is coarse so that the OS cannot distinguish the fine difference between Lucy�s time and Fred�s time. At this point I begin to see that the only way to understand this is to know how the VM and the OS negotiate hardware interrupts and how the VM manages threads and timers.
This description is all a figment of my imagination, of course.
[ November 06, 2003: Message edited by: Marlene Miller ]