• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Thread.sleep() guaranteed behaviour

 
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)?
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 504
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 504
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic