In RHE, Threads are discussed in terms of
Thread states...RUNNING, READY, SLEEPING, SUSPENDED, BLOCKING, SEEKING, WAITING and DEAD.
RUNNING, READY and DEAD happen to threads in general. SLEEPING, SUSPENDED and BLOCKING (IO Blocking) happen to threads as threads. SEEKING (an object lock on synchronized code) and WAITING (for notification that an object lock has been released) happen to threads by objects as monitors when they have synchronized code or code that sychronizes on an object.
I have a few questions...
(1) From the text, I got the impression that each object has its own WAITING pool of threads...essentially threads that are neither READY nor RUNNING because they had sought a lock on some of the object's synchronized code. Is this a correct interpretation?
I had wondered if each block of synchronized code might have its own pool. For example, for Object 1, you might not mind Thread I to have a lock on method A of Object 1 and wouldn't mind if Thread II had a lock on method B of Object 1 but in other cases you wouldn't want Thread I and Thread II to both have locks on separate pieces of code of the same object if methods A and B were interrelated to Object 1's state. You can have synchronized and unsynchronized methods but there is no granularity to synchronization.
(2) From the text, I got the impression that each thread in the WAITING state is moved to READY by notify() or notifyAll() and that if and when it achieves RUNNING status, it is able to go back to the SEEKING state for the object lock. If it succeeds, it goes back to READY with the lock. If it fails, it goes back to WAITING. Is this a correct interpretation?
I got a little confused because the arrows imply that notify() and notifyAll() moved a thread to SEEKING from WAITING but the text says that notify() and notifyAll() move the thread to READY in which case it has to wait its turn among all threads to get into the RUNNING state and then wait its turn among all WAITING threads of that object's pool to get the object lock (although in both cases there is no true notion of order of execution or "turn").
I think the arrows in the diagrams imply that for that specific object they would go back to the SEEKING state but for the JVM overall they go back to the READY state without an object lock. Either that or they are just plain confusing. However, this explains why you can't get a thread from WAITING to SEEKING in any particular order...because the thread goes to READY and the JVM Thread Scheduler doesn't guarantee an order of state change to RUNNING.
Whew!
Steve Butcher
[email protected] PS can someone please post the pointer to the famous Inner Class article?
