aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes In reference to notify maybe pausing a thread? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "In reference to notify maybe pausing a thread?" Watch "In reference to notify maybe pausing a thread?" New topic
Author

In reference to notify maybe pausing a thread?

Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
This topic was brought up in the thread

But I resurfaced it but not sure if people saw it I'm still curious about this:
Q id :958269346510
Which of the following may pause/stop the current thread?
a. calling Thread.yield();
b. calling stop() on an object of class Thread;
c. calling someObject.wait();
d. calling someObject.notify();
e. calling waitForAll() on MediaTracker Object
Correct ans : a,b,c,e
VERY similar question has been asked in SCJP2.
Answer 5 is also correct because how else will MediaTracker do it's job if it does not pause the current thread?

My question is: (besides I hope they don't ask about MediaTracker on the test ...
How come d) "calling someObj.notify()" is not a correct answer? If there happens to be some other threads waiting couldn't calling notify(), notify one of them and possibly dump the current thread into a paused state while this new thread ones (due to the scheudling of the system)? I must be missunderstanding this question because even the JQ+ study notes mention notify() as a possible way to pause another thread..
http://enthuware.com/jqplus/scjp2notes/Threads.html
Bob Graffagnino
Ranch Hand

Joined: May 30, 2001
Posts: 81
I think calling aSharedObj.notify() will only put another thread into a "seeking lock" state. Once it sees that another thread still has the object, it will go back into a wait() state.
Think about what happens when notifyAll() is called. Multiple threads are trying to grab the shared object. Once a thread locks the shared object, any threads thereafter who try to obtain the lock will see that it is locked and go back to the wait state.
Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
Originally posted by Bob Graffagnino:
I think calling aSharedObj.notify() will only put another thread into a "seeking lock" state. Once it sees that another thread still has the object, it will go back into a wait() state.[/QB]

I'm not exactly sure what you mean by "it" above. I'm thinking that if the object calls notify() it might notify some other thread that was waiting that could possibly pause the current thread that is running? This can't possibly happen from the notify() call?
Bob Graffagnino
Ranch Hand

Joined: May 30, 2001
Posts: 81
Sorry. What I meant is that calling notify() on a shared object will tell a thread, that is waiting for the shared object, to attempt to aquire a lock on the shared object. If the shared object is in use by another thread, the thread seeking the object lock will return to the wait state.
Bob Graffagnino
Ranch Hand

Joined: May 30, 2001
Posts: 81
Try running this example:

My point in the above example is that if notifyAll() gave up the object lock in Consumer's run() method, Producer would change charArr[0] to 'A' while Consumer was sleeping and then Consumer would wake up and print 'A'. If you run the program, you will see that Consumer always prints 'B', thus proving that notifyAll() doesn't give up Consumer's lock on the shared character array charArr.
On a side note, I couldn't figure out how to handle the case if Consumer finishes first (and Producer waits indefinately!). That's why Consumer's for loop iterates twice as long as Producers. If you guys can think of a way to prevent this, do share!
[ February 11, 2002: Message edited by: Bob Graffagnino ]
Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
Nice piece of coding Bob!
I'm still not so sure this answers the original question:

Which of the following may pause/stop the current thread?
(possible answer?): calling someObject.notify();

Isn't it possible a thread can still have the lock on an object and yet be paused( possibly by sitting in the ready to run state) ? Say a whole bunch of threads are running. Isn't it possible the scheduler might have to pause a thread for a while (especially maybe if a higher priority thread is woken up?). Your code would deomonstrate that this isn't the case if it's a fact that a thread can't be paused and still have the lock on an object. (My brain is fried right now so maybe this is an easy question . Bottom line is what is posted at the JQ+ study notes here
http://enthuware.com/jqplus/scjp2notes/Threads.html wrong?
If so and I get this question on the test about whether calling notify()or notifyAll() MAY cause the current thread to pause or stop running what should I answer?
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Hello Rick
When in doubt consult the API for knowing if a given method release or not the monitor. If not stated so, it doesn't release it.
Hello Bob
You could use the overloaded wait method for specifying a the maximum lapse of time to wait.
But for a real producer-consumer scenario looks for the Java Tutorial at java.sun.com
The producer should set a flag to indicate that has produced something. The consumer should reset that flag when it had consumed the stuff. Both should tested by the threads whitin a loop.


SCJP2. Please Indent your code using UBB Code
Bob Graffagnino
Ranch Hand

Joined: May 30, 2001
Posts: 81
Rick, I don't think the JQ+ study notes are correct:
From JQ+ study notes:
notify/notifyAll() : These methods simply release the locks and other thread which are waiting on them become "read to run". But CPU may or may not schedule them.

Notify()/notifyAll() tells a waiting thread to check to see if the shared object's monitor is available. It has no affect on whatever thread that currently has the monitor.
I emailed JQ+ to get some clarification from them.
Bob
P.S. Jose - yes, I know my example wasn't a real Producer-Consumer scenario. That was my original intent, but it turned into something else. I should have renamed them!
Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
Bob, I'm dying to know the answer. I don't know how to ask this question without violating Sun's rules of the test I just passed but a question about ways you can stop a thread came up. Interestingly only 1 of them is a way that we have mentioned in this thread as being for sure (wait()). I'm not sure if I should mention the other ones, but you had to pick two. I picked wait() and the other one I had to guess on. I'm thinking I guessed wrong because I did the worst in the threads section (71%). I'm dying to post the question because even now I still don't know what the correct response on the test should be.
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
I'm dying to post the question

Please don't die, but don't post the question either.


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
Rob Ross
Bartender

Joined: Jan 07, 2002
Posts: 2205
Why don't you just write all the ways you believe might stop a thread, and then we can discuss which of them work and which dont?


Rob
SCJP 1.4
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
notify and notifyAll don't release the monitor and don't stop the current thread either.
 
 
subject: In reference to notify maybe pausing a thread?
 
Similar Threads
JQ+->Threads-->waitForAll()
question in jqplus exam
Khalid mock exam question (pls help urgent)
notify() question..
JQ Plus thread question