Threads - doubt...

[Uma Viswanathan]

For the objective of exam: Recognize conditions that might prevent a thread from executing.
From Marcus Green's tutorial: http://www.jchq.net/tutorial/07_02Tut.htm
Reasons a thread may be blocked
because 1) It has been put to sleep for a set amount of time
2) It is suspended with a call to suspend() and will be blocked until a resume() message
3) The thread is suspended by call to wait(), and will become runnable on a notify or notifyAll message.
Doubt:
Can't a thread be prevented from execution if
a) yielded (entering Ready state)
b) suspended (entering Suspended state)
c) put into sleep (entering Sleeping state)
d) blocked due to I/O operations (entering Blocked state)
e) due to wait() call (entering the monitor's waiting pool and in the Waiting state)
f) pre-empted (if OS supports pre-emptive scheduling)
g) fail to acquire the monitor's lock (entering Seeking Lock state)
I think that all the above will move a thread from running state to an intermediate state. Please do guide me...
Also there is a question in Marcus's tutorial:
Which of the following are recommended ways a Thread may be blocked?
1) sleep()
2) wait/notify
3) suspend
4) pause
Answer given is sleep() and wait/notify. Is this answer correct? Why suspend() is not the answer? (since it is deprecated or any other reason).
What do they mean by "pause"?

[Ragu Sivaraman]

If i understand the question correctly..
The thread can be stopped executing(is this what you mean by blocking?)
1. yield()--- temporarily give up cpu and then content for it with other threads
2.sleep() -- due to various reasons it is sleeping
3. waiting to acquiring a lock (blocked)
4. executed wait(), inside synch code , gave up CPU/lock and waiting for notifyall
5. I/O block if any...
Now you tell me if you any doubts?
Ragu

[Uma Viswanathan]

Thanks Ragu Sivaraman for your reply.
I have doubts in Marcus Green tutorial...
Could some expert answer this please...?

[Jose Botella]

Hi Umma I find your questions very interesting

Doubt:
Can't a thread be prevented from execution if
a) yielded (entering Ready state)
b) suspended (entering Suspended state)
c) put into sleep (entering Sleeping state)
d) blocked due to I/O operations (entering Blocked state)
e) due to wait() call (entering the monitor's waiting pool and in the Waiting state)
f) pre-empted (if OS supports pre-emptive scheduling)
g) fail to acquire the monitor's lock (entering Seeking Lock state)
I think that all the above will move a thread from running state to an intermediate state. Please do guide me...

Almost all them prevent the thread from continuing being executed:
According to the Java Tutorial:
a)yield. thread won't go to not runnable state (or blocked) but it will stop execution (only) if there is another thread with the same priority. It's still in runnable state after receiving yield, and still counts for the scheduler to make it again running.
b,c,d,e) moves the thread to the blocked state. Its very important to remember that for each way of entering this state there is also the corresponding way to go out.
f)I am not sure but it seems to me that thread stays in the runnable state, just as with yield.
g) yes also blocked as Bruce Eckel states in Thinking in Java

Also there is a question in Marcus's tutorial:
Which of the following are recommended ways a Thread may be blocked?
1) sleep()
2) wait/notify
3) suspend
4) pause
Answer given is sleep() and wait/notify. Is this answer correct? Why suspend() is not the answer? (since it is deprecated or any other reason).

The API explains why suspend is deprecated.

What do they mean by "pause"?

I don't know, maybe a false answer.
But I have another question :
In the Java Tutorial it's said that the scheduler may choose to preeempt any running thread in order to execute any other thread with a lower priority to avoid starvation.
How is this statement related to f) are they the same? or maybe the scheduler can do this regarless native or green threads are used?

[Uma Viswanathan]

Thanks Jose Botella for your reply.
I feel that the options a) to g) will prevent a thread from execution.
As you had written, a thread will be blocked due to all reasons except a) and f) (i.e.,yield(),for sure and pre-emptive,which we are not sure ). Yield() moves a thread from running to ready state. So, it is not blocked.
If a question asks for reasons for a thread to become blocked and if it contains the option 'suspend'. Should we choose that option or not? (We can choose that option bcoz a thread will be blocked by suspending (or) We should not choose it bcoz it is deprecated. Which is correct?)
If the question asks for recommended way, then we should not choose that option (bcoz it is deprecated). Right?
Thanks,
Uma
PS: My name is uma

[Uma Viswanathan]

I had forgotten to add this...
yield() will not move a thread to an intermediate state, just it moves from running to ready state if the thread scheduler wishes to execute any other thread in place of the yielded thread.

[Uma Viswanathan]

Hi valentin,
I have the same understanding (whatever your diagram explains). I read RHE book but...
the exam objective "Recognize conditions that might prevent a thread from executing" and
explanationa for this objective from
Marcus's green tutorial http://www.jchq.net/tutorial/07_02Tut.htm and
JQPLUS tutorial http://www.jdiscuss.com/scjp2/notes/Threads.html
are confusing me.
Please give your answers regarding the exam objective (i.e., by what methods a thread can be prevented from execution) and also explain by what methods a thread can be blocked?
Thanks,
Uma

[Valentin Crettaz]

Uma,
I think Jose's answer above is a good one. (You can trust Jose, he is an expert )
To answer Jose's last question, the scheduler is completely dependent on the platform/OS it is running on. The scheduler will take advantage of whatever scheduling policies are implemented by the platform/OS.
Now to answer your doubts.
by what methods a thread can be prevented from execution
I'd say everything that prevents the thread from entering the RUNNING state. Or better, everything that removes the thread from the RUNNING state and makes it go to one of the four intermediary states (WAITING, SEEKING LOCK, SLEEPING and BLOCKED). In these states, the thread is NOT running.
Summing up:
- wait() will move the thread from RUNNING to WAITING.
- entering a synchronized block will move the thread from RUNNING to SEEKING LOCK.
- sleep() will move the thread from RUNNING to SLEEPING
- any blocking methods (IO,...) will move the thread from RUNNING to BLOCKED
by what methods a thread can be blocked?
As mentioned above, the only methods that move the thread from RUNNING to BLOCKED are blocking methods. Mostly IO methods like read() but also others.
I don't know if this answers your doubts, let us know if not...
HIH

------------------
Valentin Crettaz
Sun Certified Programmer for Java 2 Platform

[Jose Botella]

to Val, Thank you for the cumpliment. I keep saying the same about you in all my posts as we accorded ;-)

to Umma
Because suspend is deprecated I don't expect it to be in the exam. But if it were choose it as a passing-to-blocking-state method.
Now a coment about the states SLEEPING, SEEKING LOCK, WAITING and BLOCKED. I feel that for the exam we can manage with the diagram shown in the Java Tutorial. All the previous states would be, in this simplified scheme, the same state blocked. This is an advice for people that are daunted for so many states: regarding the exam I think the mentioned resourse is enough to understand Threads.

[Valentin Crettaz]

Originally posted by Jose Botella:
to Val, Thank you for the cumpliment. I keep saying the same about you in all my posts as we accorded ;-)

yeeeeeah right baby

------------------
Valentin Crettaz
Sun Certified Programmer for Java 2 Platform

[Uma Viswanathan]

Thank you very much Jose Botella and Valentin Crettaz.
To Jose Botella: My name is uma and not umma...
So, summing up:
We can be sure that the following methods will move the thread out of running state:
1) suspend() [enters suspended state but deprecated, so theremay not be questions regarding suspend()]
2) sleep() [enters sleeping state]
3) wait() [entering waiting state]
4) stop() [enters dead state - deprecated]
5) join() [pauses the current thread till the thread on which it has called join() dies]
The following methods may or may not leave the running state:
1) yield() [may or may not go to ready state]
2) preempted [i.e, by using setPriority or internally by OS ]
3) notify()/notifyAll() [may enter seeking lock state, if it fails to acquire lock]
4) All I/0 methods [may enter blocked state, if has to wait for something]
Following will not release the lock
1) suspend()
2) sleep()
Following will release the lock
1) wait()
2) stop()
No mention about locks for the following methods in the API:
1) join()
2) yield()
3) All I/O methods
Waiting for lock:
1) notify/notifyAll()
Uma

[Valentin Crettaz]

I think you have pretty much summarized the situation
------------------
Valentin Crettaz
Sun Certified Programmer for Java 2 Platform
[This message has been edited by Valentin Crettaz (edited November 28, 2001).]

[Jose Botella]

Hello Uma

The following methods may or may not leave the running state:
3) notify()/notifyAll() [may enter seeking lock state, if it fails to acquire lock]

These methods doesn't abandon the running state. When a thread receives one of these messages it is blocked. It becames runnable to enter the competition to be chosen by the scheduler to be runned again. Also the thread that call these methods on another thread doesn't abandon the running state until it calls wait on itself. That is why the monitors in Java are called Signal and Continue (notify and continue executing untill wait).

[Uma Viswanathan]

Hi Jose Botella,
Thanks a lot. You are correct... i was in a hurry to go to the meeting at that time...but i realized after some time i had written wrongly. So, as soon as i came out, wanted to correct it...but you had corrected it...Thanks a lot...
Actually, i must have written
[instead of the line notify/notifyAll() ]
synchronized code (enters the seeking lock state, if a thread could not acquire the monitor's lock)
and
notify/notifyAll() [A thread may be blocked (moved from waiting state to seeking lock state), if it could not reacquire the lock)
Correct Jose?
Uma