Rosemol Thanjappan

Ranch Hand
+ Follow
since Aug 08, 2000
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Rosemol Thanjappan

Mohit ,
I am extreamly thankful to you for your time and effort.
Now I can understand the thread behaviour better.

For conclusion :
When notifyAll is called on an object ,all the waited threads in this objects waiting pool , directly goes to Ready state.In the Ready state they are competing to get the object lock. In future when they gets object lock they will get executed.

I don't know whether I have to trust or not RHE diagram.

Thanking you all once again.

Rosemol.
Hi Srinivasan ,

Originally posted by V Srinivasan:
Yes Lilly,
I got it, you are right. It was my mind boggling issue for the past one week to "Explicitly" put on pen the flow of the Thread. V Srinivasan


Yes Srinivasn ,some issues may confuse us for weeks . For me this notifyAll is a an issue for a month now. I nearly read all the post in javaranch about thread ,wait notify ,just for to get my confusion an end.At last I started this thread .
And now atleast Mohit agreed with me "go back to wait state" is actually the "Ready state".
And Only one question remains now.

I am too thinking this thread is going to end very soon.

Rosemol.
Mohit,
I am thankful to you for giving me a great relief by agree with me , "go back to wait state" is actually the "Ready state". You are the first agree with me.

But there is a small question is remaining .
I started this thread believing RHE diagram on Page 219 is correct. I believed after the waiting pool all the thread goes to seek lock state before entering Ready State.
But now we all know, all the waited thread directly goes to Ready state.In the Ready state they are competing to get the object lock. In future when they gets object lock they will get executed.
So I think seek locking state explained in RHE is actually the Ready state.Thay shown as 2 different states .I am pretty sure , There is no meaning in differenciating seek locking state between Ready state .

Even if we consider, RHE uses the seek locking state for ease of explanation, The diagram they shown on Page 219 must be modified since they showed only the thread obtaining the lock enters to Ready state what happens to others? The diagram doesnot show any thing about that.

So my last question is

Is the RHE diagram is right?
IMHO it must be modified.
Please try to answer this question.
Thanking you once again,
Rosemol.
Hi Mohit,

I think ,"explicit notifyAll" works as you wrote.
an "explicit notifyAll" puts all waiting thread to ready state. One thread gets the Monitor and other threads "go back to wait state".

an "explicit notifyAll" puts all waiting thread to ready state. : Who is putting all waiting thread to ready state?
"go back to wait state" : this wait state is actually the "Ready state". am I right?

Hi, Srinivasan,
So you agree a thread needs an object lock only when it tries to execute the synchronized codes of that object(monitor).
Now we check how the "synchronized" key word is executed?
read my post on February 09-th and Mohit's post.
Of course check other posts (like maha, etc) or books(RHE etc )
about what they say about this topic.

Try to answer the questions I wrote above.
Also Which explanation is do you agree or disagree?

Please Post it.
Rosemol.

Srinivasan,
First of all I have a question.
When a thread needs an object Lock ?
Only when it executes synchronized codes of that object (monitors of that object).Yes or No?
if "No" then what are the other situations?

Give me an answer. Then we can proceed to next discussion.
Rosemol.

Hi all,
The following are my understanding of
1) Thread execute synchronized keyword
2) Thread execute wait() code
Please feel free to know if you disagree with any of them.
First check what happens
when Thread execute synchronized keyword :
Step 1) Thread is in Ready state.
Step 2) at some instance of time, The thread scheduler picks the thread and assign CPU.
Step 3) Now, Thread is running
Step 4) at some instance of time , synchronized keyword is executed in the thread. it is necessary that the thread to get the object lock of this object or some other specified object.
Step 5) The thread cannot continue until the lock is obtained . So it is blocked from execution .
Step 6) The thread scheduler puts the Thread back to Ready state
Step 7) When the lock is free , The Thread scheduler picks the thread, assigns the lock to this thread and assign CPU.
Step 8) Thread continue executing the synchronized block .
Step 9) When the synchronized block is over ,the object lock is freed .
Step 10) Thread continues executing the other codes.

Next what happens when
Thread execute wait() : .
Lets assume we are at the Step 6 of the Thread execute synchronized keyword .
Step 6) Thread continue executing the synchronized block .
Step 6.1) at some instance of time , wait() is executed in the thread.
Step 6.2) First checks whether this thread is the owner of the object lock on which wait() is called.
If "no " IllegalMonitorStateException is thrown.
If "yes" next step .
Step 6.3) The thread scheduler frees the object lock , and puts the thread in waiting pool of the object.
Every operation about wait() is over Now.
The threads in the waiting pool are waiting for scheduler to get them out of waiting pool.The Scheduler needs notify()/notifyAll/timeout to put them to Ready state. In the wait state they are not waiting for object lock or any thing else they are just waiting for scheduler to get them out of waiting pool.

When some other thread have this object lock, notifies or timeout for waiting is over ,The thread scheduler picks one of the thread from this objects waiting pool and puts the thread in Ready state.
[If it was notifyAll () The thread scheduler picks all of the threads from this objects waiting pool and puts the threads in Ready state.]
Next the thread have to continue the execution of the synchronized code. So continues from Step 7 of the Thread execute synchronized keyword .
Step 7)When the lock is free ,the Thread scheduler picks the thread, assigns the lock to this thread and assign CPU.
Step 8) Thread continue executing the synchronized block .
Step 9) When the synchronized block is over ,the object lock is freed .
Step 10) Thread continues executing the other codes.

Originally posted by Cherry Mathew:

I want to get one more doubt clarified.
I know that when a wait() is called the thread goes into the wait state but will a thread go into the wait or blocked state when it is tries to execute a synchronized block where lock is with another thread.

Wont it be better if all the threads waiting for the lock goes into the wait state and notify() method called at the end of each synchronized block.


Cherry ,

All the threads waiting for the lock ,not goes into the wait state that is "waiting pool " of the object .

Don't confuse with execution of synchronized keyword and execution of wait() .
synchronized keyword : All the threads waiting for the lock, all goes to Ready state, just blocked from execution .When the object lock is free the scheduler picks them and assigns the object lock. There is no need for notify()/notifyAll().
wait() : All threads called wait() goes to waiting pool of the object. Needs notify()/notifyAll/timeout go to Ready state. In the wait state they are not waiting for object lock. They are just waiting for scheduler to get them out of wait state.

Please feel free to know if you agree or disagree with any of them above.
Rosemol.

Hi Jane ,Peter ,Velmurugan,
Thank you for clarifying my doubt.I apreciate your time and effort.
To conclude on RHE :Page 219 they provided a diagram to show monitor state.
They says after notify()/notifyAll() the threads goes to seeking lock state. Is there a seeking for lock , is actually happening before entering Ready state?
From the above discussions, IMHO they are directly goes to Ready state .
[ and remains blocked from executing till scheduler picks the thread and assign the object lock.]
Is the RHE diagram is right? IMHO it must be modified.
It would be great help if you can verify this also ?
Thanking you
Rosemol.
Hi Jane,
Thank you for your explanation.

After notifyAll ,Only one thread obtains the object lock . All otres will surely wait for lock. I agree with this.
The question is
Whether The threads fails to aquire lock goes to waiting pool .And continue to wait to get another notify ?

While I coding , it seems to me that all the threads get out of the waiting pool due to notifyAll() call will remain in Ready state. When they get object lock they will continue to excute.
My code :

Rosemol.

Hi venkat_alladi,
The Rule is : initialization of a local variable must be done explicitly before the value is used .
In the first program you are using the value of f to read(). So it compiler ensures wherther it is initialized or not.
In the second program you are not using the value of f any where in the program.So no compiler error.
By the way your code shows this Compiler Error first:

" f is already defined in main(java.lang.String[])
catch(FileNotFoundException f){ "

just use any other identifier instead of f .
Hope this may help....
Rosemol.

Peter,
"Every thread in the wait set for the object is removed from the wait set and re-enabled for thread scheduling."
That means those threads in the wait set for the object is now in Reday state.And only one thread gets object lock.

What happens to other threads ?
Jane and Velmurugan says they are return to waiting pool of the object.
But IMHO they won't. When I wrote some code it seems to me that "They remains in Ready State competing for object lock."
They are not returning to waiting pool to get notify again.
Can you please verify this?
Thanking you
Rosemol.

Hi Velmurugan Periasamy,

RHE says (P.205)
Ready : Not waiting for anything except the CPU.
As you said seeking for lock is going on in the ready state?
RHE says a waiting thread after seeking for lock and obtaining lock the thread enters to Ready state.
this is what I can't understatnd.
Could you explain a little bit more.
Thanking you
Rosemol
Hi ,
"NotifyAll moves all threads in the monitor�s waiting pool to ready."
I am little bit confused here. Is all the threads goes to ready state? I think only one thread aquires the object lock, and goes to ready state .
Please explain .
Thanking you
Rose
Hi Maha,
Are you sure about these situations cause
InterruptedException?

IMHO they won't .

(ii) When another thread calls myT.notify()
(iii)When another thread calls myT.notifyAll()


From java API :
public class InterruptedException extends Exception.
Thrown when a thread is waiting, sleeping, or otherwise paused for a long time and another thread interrupts it using the interrupt method in class Thread.
Please check it out.

Originally posted by maha anna:

3. The 3rd method is wait(..)
This again has to be inside try-catch-Inter...Excep.. block. A thread myT ,which called wait(..) may throw InterruptedException in 3 occations.
(i) When another thread calls myT.interrupt()
(ii) When another thread calls myT.notify()
(iii)When another thread calls myT.notifyAll()

[This message has been edited by maha anna (edited April 27, 2000).]


Thanking you .
Rosemol.
Hi Kishore ,
Congratulations......

Originally posted by Kishori More:

At the end I had 5 questions about which I was
not sure. Out of these 5 questions, for 3 questions
it was mentioned SELECT 2 ANSWERS. And I was sure
about a single answer to be correct! For each of
these 3 questions - no other answer was correct.
But the summary sheet at the end was showing these
3 as incomplete questions.
I prayed the GOD & selected 2nd answer for each of
these 3 questions. And I finished the Exam.
I was unlucky to get such questions.
Mr. Marcus Green has mentioned in one of his mock
exams," If u r really sure , no answer is correct,
Don't mark any answer . U will get the marks."
I did the mistake, I want to warn my friends ,
stick to what u know.

Kishori K. More


What you meant by the summary sheet ?
This is the first time I am hearing about that.
Please discribe what is it ?
Thanking you
Rosemol
24 years ago
Hi Chris,
You cannot use Member initialization with the declaration has exception problems:
- cannot call methods that throw a checked exception.
- If you need to deal with errors you can put the initialization code along with try/catch statements.
case 1: for instance fields
a) either in a constructor ()or
b) instance (non-static) initialization blocks
case 2: for static fields.
in a static initialization block

In this code the constructor
RandomAccessFile(....) thows FileNotFoundException.
So you have to put the code in try-catch block.
Since it is an initializer statement rather than a code block we can't use the try-catch block here.
Try the alternatives.
Put it in a instance (non-static) initialization blocks with try-catch .

Example :

Rosemol