This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Thread.sleep() guaranteed behaviour Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Thread.sleep() guaranteed behaviour" Watch "Thread.sleep() guaranteed behaviour" New topic
Author

Thread.sleep() guaranteed behaviour

Vad Fogel
Ranch Hand

Joined: Aug 25, 2003
Posts: 504
Is there any guarantee that the output from the modified K&B code will always produce an ordered sequence of "Fred" "Lucy" or "Lucy" "Fred"? Is it guaranteed at all that both threads will eventually run at least once (the sleeping interval is now 1)?
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391

Is there any guarantee that the output from the modified K&B code will always produce an ordered sequence of "Fred" "Lucy" or "Lucy" "Fred"?

Hi Vad. I changed 4 to 100 in your program and ran it. I got two Lucy�s in a row and later two Fred�s in a row.

The two threads could be running in two different CPUs. In this case, the timing of the output of one thread has no bearing on the timing of the output of the other thread.

Is it guaranteed at all that both threads will eventually run at least once (the sleeping interval is now 1)?

I am curious to know if either of the follow questions is equivalent to your question.
If application terminates and no thread called System.exit() then all user threads have run to completion?
The scheduler of the virtual machine will always eventually execute every runnable thread?
Vad Fogel
Ranch Hand

Joined: Aug 25, 2003
Posts: 504
Hi Marlene! I see almost nothing is guaranteed on a single CPU. But I thought when a thread goes to sleep, all other threads in a runnable pool should get a chance to execute. If the sleeping thread doesn't carry the lock over, of course. So, both threads of the same priority must somehow take turns and execute. Is it guaranteed though?
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
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 ]
Vad Fogel
Ranch Hand

Joined: Aug 25, 2003
Posts: 504

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.

At this point I also begin to see something: this matter is so convoluted, it'd better be kept away from appearing in subtilities on the real thing.
But thank you very much Marlene!
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Well, I don't think it is convoluted. The code that manages threads and timers is probably all very organized with lots of nice data structures, but complex. I say organized, because it is pure internal stuff, away from the unruly user interface. It certainly is curious how the VM and the OS negotiate interrupts.
I work on applications against the edge of this kind of stuff. I get to know the systems programmers and they show me their code and designs. It's facinating to me, as you can tell. But you have to read the code to know what's going on.
A key point is, setting a timer requires help from the OS --I guess-- and thus is platform dependent.
[ November 06, 2003: Message edited by: Marlene Miller ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread.sleep() guaranteed behaviour
 
Similar Threads
Unexpected result with Threads join() method...
Threads Again
Is Kathy Sierra right when she said "Each thread will start, and each thread will run to completion"
join, a Thread question
Threads