This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Dan's: Blocked vs Waiting - possible mistake Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Dan Watch "Dan New topic
Author

Dan's: Blocked vs Waiting - possible mistake

Alfred Kemety
Ranch Hand

Joined: Aug 14, 2002
Posts: 279
In one of Dan's questions, it asks:
Which of the following will force a thread to move into the blocking state?
Thread.join method.
Thread.sleep method.
Object.wait method.

are correct answers... I thought Object.wait() moves it to the Waiting state, Thread.sleep() tp the Sleeping state, not the Blocked one..
About join() I'm not sure the API says "Waits for this thread to die." so maybe it moves it to the Waiting state or Blocked state, it's not clear.
Maybe the question should ask, "Which of the following will force a thread to move into the Non-runnable state?


Alfred Raouf - Egypt - SCJP 1.4<br />Kemety.equals(Egyptian) // returns true
Shishio San
Ranch Hand

Joined: Aug 29, 2002
Posts: 223
Originally posted by Alfred Kemety:
In one of Dan's questions, it asks:
Which of the following will force a thread to move into the blocking state?
Thread.join method.
Thread.sleep method.
Object.wait method.

are correct answers... I thought Object.wait() moves it to the Waiting state, Thread.sleep() tp the Sleeping state, not the Blocked one..
About join() I'm not sure the API says "Waits for this thread to die." so maybe it moves it to the Waiting state or Blocked state, it's not clear.
Maybe the question should ask, "Which of the following will force a thread to move into the Non-runnable state?

IMHO, the blocking state includes the waiting state (a call to wait or waiting for I/O operation to finish) and the sleeping state. and all are also called non-runnable state since the thread isn't running.

Making a Thread Not Runnable
A thread becomes Not Runnable when one of these events occurs:
Its sleep method is invoked.
The thread calls the wait method to wait for a specific condition to be satisifed.
The thread is blocking on I/O.

Reference


Whatever doesn't kill us ...<br />Is probably circling back for another try.<br />SCJP 1.4
Shishio San
Ranch Hand

Joined: Aug 29, 2002
Posts: 223
Here's another point of view. The difference btw wainting and blocked

Waiting
Thread has been asked to wait. (by means of wait method)
The thread already acquired the lock and executed some synchronized code before coming across a wait call.
Can move to ready only when it gets notified (by means of notify or notifyAll)


Blocked
Thread is waiting to get a lock on the monitor.
(or waiting for a blocking i/o method)
Caused by the thread tried to execute some synchronized code. (or a blocking i/o method)
Can move to ready only when the lock is available. ( or the i/o operation is complete)
Alfred Kemety
Ranch Hand

Joined: Aug 14, 2002
Posts: 279
But isn't the quote you included Shishio actually differentiate between Sleeping, Waiting, and Blocking? It simply says that non-runnable is one of the 3, but the 3 are not 1. Not like the my christian Trinity
They are all non-runnable but they're not all in a blocked state.
This distinction is also made clear in Mughal's book, diagram at page 283, and discussion in page 284.
One more thing to prove that Blocked state is different from waiting state for instance is that a notify() call can't get a thread from the blocked state to ready-to-run state.

The blocking operation must complete, before the thread can proceed to the Ready-torun state.

and a blocking operation is for instance a call to an I/O method, or trying to execute a synchronized statement on an object locked by another thread.
or am I missing something?
Shishio San
Ranch Hand

Joined: Aug 29, 2002
Posts: 223
Hi,
I do share your opinion. I think though that i read somewhere about what i said in the the first post. Maybe we should just let Dan justify his answer this time.
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
The Java Language Specification intentionally provides only a vague definition of threads. The intent was to allow for quick and easy development of JVMs that can run on top of existing platforms. For example, thread scheduling on a Windows PC is done on a time-slice basis but a UNIX system will depend more heavily on thread priorities.
The JLS does not define the details of the design such as the names of thread states. For that reason, there is not one set of thread state names that is used by all authors of books and mock exams. When I started developing my thread exam I initially used the term "Sleeping State", but then I decided that the term sounded like it was only associated with the Thread.sleep method. I switched to "Blocking State" because it sounds more generic.
Chapter 17 of the JLS covers threads. The word "blocking" never appears in the entire chapter. Similarly, the terms "runnable" and "non-runnable" never appear. The only term I found in the JLS that refers to the state in question is "dormant". Unfortunately, I have never seen that word used in print anywhere else in regards to thread states so I don't want to be the first to adopt it.
Given a choice between generic terms such as "non-runnable" or "dormant", I would probably select "dormant" since it is used once in Chapter 17 of the JLS while "non-runnable" is never used. The term "dormant" is a little more descriptive since its meaning is clear in any Latin based language while the term "non-runnable" sounds like a consequence of not implementing the "Runnable" interface.
In summary, the lack of a clearly defined set of thread state names means that Java programmers will continue to have this discussion for many more years.


Dan Chisholm<br />SCJP 1.4<br /> <br /><a href="http://www.danchisholm.net/" target="_blank" rel="nofollow">Try my mock exam.</a>
Alfred Kemety
Ranch Hand

Joined: Aug 14, 2002
Posts: 279
While you're right Dan in almost all what you said, there's one more fact about the JLS, it states exactly what a "Waiting" thread means, A waiting thread is a thread that is in the "Wait set" of an object after a wait() call on this object from this thread. It's waiting for:
1- a specific time to elapse,
2- a call to notify() on the same object from another thread - and then it might not even be chosen to leave the "Wait set" to the ready-to-run state,
3- a call to notifyAll() on the same object from another thread.
It's not waiting for a blocking operation to be finished, and if a blocking operation happens, while the thread is executing - although it's not clear in the JLS - I don't see it as a reason for the thread to be in the "Wait set" since a notifyAll() shouldn't actually get the Thread into the ready-to-run state but the end of the blocking operatin should.
It's VERY nicely explained in the JLS

Every object, in addition to having an associated lock, has an associated wait set, which is a set of threads. When an object is first created, its wait set is empty.
Wait sets are used by the methods wait, notify, and notifyAll of class Object. These methods also interact with the scheduling mechanism for threads.
The method wait should be called for an object only when the current thread (call it T) has already locked the object's lock. Suppose that thread T has in fact performed N lock actions that have not been matched by unlock actions. The wait method then adds the current thread to the wait set for the object, disables the current thread for thread scheduling purposes, and performs N unlock actions to relinquish the lock. The thread T then lies dormant until one of three things happens:

Some other thread invokes the notify method for that object and thread T happens to be the one arbitrarily chosen as the one to notify.
Some other thread invokes the notifyAll method for that object.
If the call by thread T to the wait method specified a timeout interval, the specified amount of real time has elapsed.
The thread T is then removed from the wait set and re-enabled for thread scheduling. It then locks the object again (which may involve competing in the usual manner with other threads); once it has gained control of the lock, it performs additional lock actions and then returns from the invocation of the wait method. Thus, on return from the wait method, the state of the object's lock is exactly as it was when the wait method was invoked.

there's more in the JLS about Wait sets and Notification, chapter 17.14
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
Alfred,
I agree that a wait state of some sort does indeed exist, however, I used the term "blocking" because I was looking for a generic term to describe the wait, sleep, and blocking state. Blocking seems to be the most generic of the three and also seems to be widely understood.
I am familiar with the JLS quote. It happens to contain the term "dormant" that I referred to earlier.
At this point, I think that the world of Java still lacks a universally accepted definition of the thread states. However, if you run across one I would love to see it.
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Hey Dan,
I am quite happy with the term given in the Java Tutorial: Not runable Though this must be thought as a generalization of several states. It is also helpful to remember that for each distinct way to enter into this estate there is only a corresponding way out. For instance if blocked on IO, the IO must complete...etc


SCJP2. Please Indent your code using UBB Code
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
It sure would be nice if the authors of the JLS, the tutorial, and other books on the subject could come to an agreement on the names of the thread states and the topology of the state diagram.
I don't have any particular affection for one term or the other. I don't see anyone posting in defense of the "blocking" term but there does appear to be a lot of support for the "not-runnable" term. O.K., I'll go ahead and make the change on my exam.
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy debaters, I'm going to add that Dan's use of the term is actually OK, because some folks *do* group ALL non-runnables into a category called blocked, even though there are further distinctions that can be made.So the word "blocked" can be used to mean TWO different things, and some folks at Sun *do* use the word "blocked" in just the way Dan uses it.
We normally prefer "non-runnable" and tried to clarify that in the 1.4 exam (it used to say things like, "what will cause a thread to stop" and nobody knew what that meant -- stop as in DIE or stop as in become non-runnable for some reason...)
If you come across 'blocked' in a question, you do NOT need to worry about the more narrow definitions of blocked, and can think of it the way Dan used it -- as a generalized grouping word for All Things Non Runnable (but still alive).
So Dan, I say be daring! Use the word "blocked" with abandon
cheers,
Kathy "plays fast and loose with the language" Sierra
(p.s. I am trying to think of other examples where we use terms in a way that some call "sloppy", but that are acceptable anyway -- for example, we sometimes use the term "override" to describe what you do when you implement the methods of your abstract superclass. *Technically* it is not really an override, but because implementation and overriding follow the same, exact rules, we just lump it all into one to make it simpler. If I think of other examples, I'll post them...)


Co-Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007124/ref=jranch-20" target="_blank" rel="nofollow">"Head First Design Patterns"</a><br /> <br />Just a Jini girl living in a J2EE world.
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
Thank you Kathy!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Dan's: Blocked vs Waiting - possible mistake