• 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
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Interrupt method + volatile modifier?

 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi amigos,
I have a tiny question. Are the volatile modifier and the interrupt method appearing in the exam?
Gracias in advance...
Marx
 
Bartender
Posts: 6663
5
MyEclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, both of them appear on the exam. I am talking about SCJP 1.5 I dont know about the 1.4 version
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can anyone provide more detail on what we need to know regarding interrupt()? I do not recall reading about it in the K&B book. If it's there and I just missed it, if someone could point that out too I'd appreciate it.

Thanks.
 
Ranch Hand
Posts: 584
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sato,

The following question is from WhizLabs. Such question covers the interrupt() method.

Please try to answer it by yourself. I will provide the correct answer later.

Given the following run method of a thread, which are the ways in which a thread will surely come out of the waiting state ? (Choose all that apply)


a) Another thread which owns the lock of the object invokes notify();

b) Another thread which owns the lock of the object invokes notifyAll();

c) Compilation fails.

d) The time period of 5 seconds has elapsed.

e) Another thread invokes join() on the thread.

f) Another thread invokes interrupt() on the thread.

g) Another thread invokes resume() on the thread.

h) An exception is thrown at runtime.
[ April 17, 2006: Message edited by: Edisandro Bessa ]
 
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Edisandro

Given the following run method of a thread, which are the ways in which a thread will surely come out of the waiting state ? (Choose all that apply)

code:
--------------------------------------------------------------------------------

public void run(){ synchronized(this){ try{ wait(5000); } catch(InterruptedException ie){} }}

--------------------------------------------------------------------------------



a) Another thread which owns the lock of the object invokes notify();

b) Another thread which owns the lock of the object invokes notifyAll();

c) Compilation fails.

d) The time period of 5 seconds has elapsed.

e) Another thread invokes join() on the thread.

f) Another thread invokes interrupt() on the thread.

g) Another thread invokes resume() on the thread.

h) An exception is thrown at runtime.



I think answer would be b,d and f.

Please confirm

Thanks
 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
a, b, d, f are the possible answers
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a question about that...
I think answer A is wrong, because notify() only notifies ONE OF the waiting threads (as opposed to notifyAll()), and that lucky thread is not guaranteed to be ours. So I think notify() is not a mean to get our thread to "surely come out of the waiting state".
Or did I miss something ?
 
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I think the answers are d and f.
Read the question carefully. The question is which thread will surely ...

Even if notify() is invoked on an object, a thead in waiting state to acquire monitor will not get object monitor unless the thread that invoked notify() has finished execution and the current thread has been selected to acquire lock. Hence the correct answer is d and f. Let me know if this helps.

Regards
Abhijit
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would go with B, D and F due to following reasons.

1) Some other thread invokes the notify() method for this object and thread happens to be arbitrarily chosen as the thread to be awakened.
2) Some other thread invokes the notifyAll method for this object.
3) Some other thread interrupts thread T.
4) The specified amount of real time has elapsed, more or less. If timeout is zero, however, then real time is not taken into consideration and the thread simply waits until notified.

from 1) we can't say the thread will be the same one which is in waiting state will be notified so answer A will go down.
 
Edisandro Bessa
Ranch Hand
Posts: 584
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The correct answers are : B, D, F.

When notify() is invoked by a thread which is the owner of the lock, it will bring the one of the waiting threads out of the wait state. There's no way to predict which thread will be chosen. So choice A will not ensure that a thread will come out of the waiting state.

When notifyAll() is invoked, all the waiting threads will come out from the wait state and go for runnable state.

Abhiji has highlighted a very interesting question :


Read the question carefully. The question is which thread will surely ...

Even if notify() is invoked on an object, a thead in waiting state to acquire monitor will not get object monitor unless the thread that invoked notify() has finished execution and the current thread has been selected to acquire lock. Hence the correct answer is d and f. Let me know if this helps.



I think you missed this choice because you thought the term "surely come out" would implicitly put the thread in the running state.

But this choice is correct because even the waiting thread could not be able to get the lock, it still will leave the waiting state and enter in the runnable state.

The same analysis is also valid for wait(5000) call. Surely after at least 5 seconds has elapsed the thread will leave the waiting state and enter in either running or runnable state.

Be carefull when asked about wait() method. Here, the wait(5000) call assures that AT LEAST five seconds has elapsed and not exactly five seconds. It's a minimum value not a maximum.

The join() method causes the current thread to stop executing till the thread it joins with completes, but it does not cause it to come out the waiting state. If interrupt() is invoked on a waiting thread, InterruptedException is thrown and the thread comes out of the waiting state.

Choices C and H are ridiculous. The code compiles and runs fine.
 
reply
    Bookmark Topic Watch Topic
  • New Topic