File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Threads yield( )

 
Deepali Pate
Ranch Hand
Posts: 114
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yield puts thread in waiting state //t
To this Maha Aana says
It is false and this is expln given
yield() puts the thread back to Ready state
When yield() is called, the thread on which it is called yields the execution slot to another thread (who are in ready state).
maha anna
I agree it yields to the thread which is in ready state but the thread which calls yield doesnt it go to waiting state.
Please clarify
Thanks
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First off, yield() is a static method, so there is no way of invoking yield() on a specific thread instance. It is the scheduler's job to decide which thread instance gets to run next.
From the API:

public static void yield()
Causes the currently executing thread object to temporarily pause and allow other threads to execute.

The comment is not really descriptive but a common agreement is that the scheduler (implementation-specific) is the one that decides which thread (of the same or higher priority) gets to run.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13045
6
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since the term "wait" has a very specific meaning with respect to Objects and Threads that question could have been worded better.
Note that exactly what happens to the Thread that calls yield() depends on the JVM and whether or not there are other threads waiting to run. If the JVM decides to let another Thread run, the first Thread will join all others waiting for execution.
(I dunno if that is a better way to say it - easy to get tangled up in the use of "wait")
Bill
 
Corey McGlone
Ranch Hand
Posts: 3271
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Deepali Pate:
I agree it yields to the thread which is in ready state but the thread which calls yield doesnt it go to waiting state.

No. There are two distinct states that I think you're confusing. There is the waiting state (in which case a thread in blocked and waiting for something, such as a resource that is locked) and there is the ready-to-run state (in which a thread is ready to go but doesn't currently have access to the processor.
If a thread loses access to the processor, either voluntarily or involuntarily, it moves to the ready-to-run state. It can later be moved to the running state when it gets its turn.
When a thread is executing and finds that it does not have access to some resource (let's say a locked object), it is forced to wait. It, therefore, gives up the processor and moves to the waiting state.
I hope that helps,
Corey
 
Deepali Pate
Ranch Hand
Posts: 114
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok let me put it this way. A thread say 't' calls yield(). So that means t was in running state and after yield(ie. relinquish CPU) goes to what?(Ready or Ready to run)??? but now clear to me that surely not wait state.
Next after t has yielded the CPU then if there were threads t1, t2, t3 ....... waiting for CPU resource in ready-to-run state then they take up the CPU but which one would get would depend on the implementation platform.
Have i got it right???
So now back to my first post:
"yield puts thread in waiting state"
would be false as it is goin to either Ready or Ready-to-run.
Someone add ur comments to this.
Thanks
So the answer to my very first question
 
Corey McGlone
Ranch Hand
Posts: 3271
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Deepali Pate:
...(Ready or Ready to run)???...

These are really one in the same.
The states of a thread are as follows:
ready-to-run
running
waiting
sleeping
blocked
dead
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is an attempt at showing the life cycle of a thread: http://www.valoxo.ch/ThreadsLC.pdf
 
Deepali Pate
Ranch Hand
Posts: 114
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Corey,
Thanks for the clarification.
So i assume what i have understood is right and yield() is right. Except that i now have to remember that Ready and Ready-to Run are one and the same states.
 
Tybon Wu
Ranch Hand
Posts: 84
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yield tells the scheduler to change the current thread from running state to ready state, put it at the end of the ready queue, and dispatch the next thread from the ready queue
 
Deepali Pate
Ranch Hand
Posts: 114
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to everybody for the clarifications i think it is all cear now.
 
Corey McGlone
Ranch Hand
Posts: 3271
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tybon Wu:
...put it at the end of the ready queue, and dispatch the next thread from the ready queue

NO!
The JVM has no control over which threads are being executed. For the most part, it can only make "recommendations" as to what should happen. For sure, if you invoke the yield method, the underlying OS can choose any of the threads in the ready state to run (perhaps even the one that just invoked yield). Threads are not necessarily executed in a round-robin fashion. Some OS's may do this, but not all. From Java, you have no control over this.
Corey
 
Anthony Villanueva
Ranch Hand
Posts: 1055
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even setting priorities on your threads will not explicitly guarantee which thread gets the scheduler's nod to go next.
Maybe this link might help. Cheers!
 
Tybon Wu
Ranch Hand
Posts: 84
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes you're right JVM can call OS primatives, but of course their implementations are OS dependent. My statement was oversimplified
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic