• 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

stop does release the lock

 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This code tries to show that stop does release the monitor.
The thread toStop is started. It prints "ToStop still running" forever after having started the thread test. This second thread prints "test has started and now is waiting to adquire the lock" and it mus wait for the thread toStop is stopped because both threads has been synchronized over the same object (test).
Thereafter the thread test is not allowed to print "test has the lock and ends" until the monitor hasn't been released.
The output is
"
ToStop still running
test has started and now is waiting to adquire the lock
test has the lock and ends
"
I we comment out toStop.stop() the output is
"
ToStop still running
test has started and now is waiting to adquire the lock
ToStop still running
ToStop still running
ToStop still running
ToStop still running
ToStop still running
...
"

Notes:
A) If we comment out while(!test.isAlive()) {} There is not output at all because we are stopping stop before test has started.
B) If we commented out test.star() (in run) and we placed it after while(!toStop.isAlive()) the output would be
"
test has started and now is waiting to adquire the lock
test has the lock and ends
"
Though we wait that toStop starts before starting test, test executes its run before toStop executes his. Thus we don't see
"ToStop still running" in the output. Any comment on this?
 
Ranch Hand
Posts: 3244
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jose
The stop method is deprecated.

------------------
Dave
Sun Certified Programmer for the Java� 2 Platform
 
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
Really? I haven't noticed it. :-)
Any comments more interesting?
 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Jose,
toStop could well never acquire the lock - the javadocs for isAlive state that the method

Tests if this thread is alive. A thread is alive if it has been started and has not yet died.


but the relationship between start() and run() is asynchronous - a thread can be started without it having entered run() yet.

Really? I haven't noticed it. :-)
Any comments more interesting?


sarcasm is probably not the best way to stop a discussion thread - perhaps that should be deprecated, too.
cheers, dan.
 
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
Hi Dan


toStop could well never acquire the lock .


Do you mean the run method of the class ToStop has not the lock associated with the object test when it starts the other Thread, or when prints ToStop still running?


the javadocs for isAlive state that the method isALive tests if this thread is alive. A thread is alive if it has been started and has not yet died.


I agree but I don't see any relation with your previous sentence.


but the relationship between start() and run() is asynchronous - a thread can be started without it having entered run() yet.


I agree. I think note b is about that.


sarcasm is probably not the best way to stop a discussion thread - perhaps that should be deprecated, too.


I don't think the discussion had even started. I intended to boost it.

 
dan moore
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Jose,
looks like i misunderstood your query - thought you were questioning why you see the behaviour in point B, because you were misunderstanding isAlive() behaviour, which is not necessarily intuitive.
so, [the thread represented by] toStop could well never acquire the lock in the scenario described in point B. when printing "toStop still running", toStop definitely has the lock, because it is within the synchronized block. toStop does not start the test thread in scenario B, as that call is made from the main thread.
toStop might never acquire the lock, since it is undefined when the toStop.stop() (on the main thread) is performed in relation to the running of the toStop thread.
it is surprising in that it seems like test runs first when started second (this is your main query? apologies, i am a bit on the slow side ). do you always get this result?
when running the code from scenario B on my machine (i repost the code here as a double-check) i have seen output both with and without toStop printing its "running" statement.

interestingly enough, i got the output;
ToStop still running
test has started and now is waiting to adquire the lock
test has the lock and ends
the first time i ran the code (and one other time - probably about 1 in 30 times so far). otherwise it never prints "ToStop still running".
hmm. the while(!toStop.isAlive()) loop never seems to get run - not sure if this is by definition (perhaps some ambiguity there) but it is reasonable to assume the call to toStop.start() sets the flag reported by isAlive() to true.
my first guess was that the VM work required to enter the toStop synchronization block is greater (more time consuming) than work to enter the test block. probably because the monitor in test is synchronized on itself. if you look at the bytecode for both classes (javap -c <class>) there is a difference. however, restructuring code so that monitors synchronize on the toStop instance doesn't really change anything.
i think the answer is that it is not really a race between the toStop and test threads (as it looked at first to me), but a race between the main thread and the toStop thread.
it shows that it is unlikely that toStop will actually start running, acquire lock and print out its statement before the main thread that started it manages to call toStop.stop(). in fact, quite probable that the toStop thread is stopped before either toStop or test actually runs.
does that make sense? thanks for question, caused me a lot of confusion for something so small.
cheers, dan.
 
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
Hi Dan thanks for answering.
My intention was to show that stop releases the lock because I have read that the reason why it was deprecated is because it didn't do it so. However I trust the API for this matter (as usual)


my first guess was that the VM work required to enter the toStop synchronization block is greater (more time consuming) than work to enter the test block.


That was what I thought also.


i think the answer is that it is not really a race between the toStop and test threads (as it looked at first to me), but a race between the main thread and the toStop thread.
it shows that it is unlikely that toStop will actually start running, acquire lock and print out its statement before the main thread that started it manages to call toStop.stop(). in fact, quite probable that the toStop thread is stopped before either toStop or test actually runs.
does that make sense?


Yes I agree entirely.
I think we can conclude that isAlive only garantees that the thread is now in runnable state. Deciding when the run method is going to be called is a work for the sheduler, especially regarding a comparation with the main thread.
There is another point I have learnt: to make certain a thread is "started" after another, make the latter invoke the former within its run method.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic