• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

In reference to notify maybe pausing a thread?

 
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bob Graffagnino
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I'm dying to post the question


Please don't die, but don't post the question either.
 
Bartender
Posts: 2205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
notify and notifyAll don't release the monitor and don't stop the current thread either.
 
I've read about this kind of thing at the checkout counter. That's where I met this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic