|
|
We saw earlier various method calls that can cause the thread to come out of running state, it goes either in ready-to-run state or not-ready-to-run states (waiting, sleeping or blocking) or in dead state. Let us summarize different methods associated with each of these state transitions of a thread.
|
|
The objective 7.2 wants to test your knowledge of these conditions. Though the wording of this objective is a bit confusing (“Recognize conditions that might prevent a thread from executing.”), remember that it really wants to test your knowledge about conditions (a call to methods such as sleep(), yield() and join() or setting priorities) that can drive an executing thread out of the running state. |
Running to ready-to-run state
1. A thread moves from running to ready-to run state when it calls the Thread.yield() it its run method. The thread may immediately gains back its turn if thread scheduler decides so. But typically other threads of the same priority can have a chance.
|
@ |
One misconception about yield() is that it gives fair chance of scheduling to all threads (with same priority or higher priority) in thread pool. But remember that when the thread scheduler is priority-based, it is likely to schedule the higher priority thread is irrespective of whether the currently executing thread yields or not. The whole purpose of yield is to create an opportunity for other threads that have same priority |
2. There are other reasons when the thread scheduler moves the thread from running to ready-to-run state. However, these reasons are implementation dependent and hence are not guaranteed. For example, in a priority-based implementation, the thread scheduler may move a currently executing thread, if a new thread with higher priority appears in the thread pool. Or in time-sliced implementation, the scheduler will move the thread from running to ready-to-run state when its allocated time is over.
Running to not-ready-to-run states
A thread moves from running to one of three not-ready-to-run states- sleeping, waiting or blocked.
1. A call to sleep()immediately moves from running state to sleeping state. Therefore, it guarantees that the current thread will stop executing for at least the specified time. Note that you can interrupt a sleeping thread before the specified sleep duration by a call to the interrupt() from the current thread.
2. A call to join()also immediately stops current thread from running. The current thread is moved from running to waiting state. It remain in that state until the thread it joins with (that is the thread it has called the join()on) completes its execution and becomes a dead thread. After that, this thread is moved back to the thread pool to contend for its turn to execute.3. A call to wait()on an object also causes the thread to move out of running state ( and goes in waiting state). We will see the details in next section. For now, remember that a thread waits because it cannot access an object required for its execution ( as it cannot acquire the lock on the object whose code it attempts to run).
Running to dead state
A thread moves from running to dead state when -
1. The thread’s run() method completes and returns.
2. A call to System.exit(0); in the thread’s run() method.
A call to a thread’s stop() method also moves it from any state it might be to a dead state. However, this method is deprecated because it is unsafe and hence it should not be used.
|
|
Though very little is guaranteed, be extra careful at the questions which asks you a probable behavior (For example, is it possible…. ? or which of the following can be done….? ). There is lot of behavior in threads, which is not guaranteed, but it is possible. You might answer incorrectly if you do not pay attention to what exactly (possibility or guarantee) the question is asking. |
