Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   I donít understand how new approach to suspending, resuming threads is any safer thanÖ (http://www.velocityreviews.com/forums/t622095-i-don-t-understand-how-new-approach-to-suspending-resuming-threads-is-any-safer-than.html)

Srubys@gmail.com 06-24-2008 11:44 PM

I donít understand how new approach to suspending, resuming threads is any safer thanÖ
 
hiya

Iím reading a tutorial on suspending, resuming and stopping threads.
Its argument on why suspend(), resume() and stop() should not be used
is because if thread gets a lock on critical data structures and then
gets suspended, those locks may not be relinquished. Then tutorial
suggest we should instead use flag variables combined with wait() and
notify().

I donít see how that makes anything safer. Just as you can get a lock
on critical data structure and then suspend a thread using suspend(),
you can also get a lock on critical data structure and set a flag in
such a way, that thread gets suspended ( via wait() ). In both cases
result would be the same. So how is the latter safer? Itís just a
different syntax, but same end result!


thank you

Arne VajhÝj 06-25-2008 12:02 AM

Re: I donít understand how new approach to suspending, resuming threads is any safer thanÖ
 
Srubys@gmail.com wrote:
> Iím reading a tutorial on suspending, resuming and stopping threads.
> Its argument on why suspend(), resume() and stop() should not be used
> is because if thread gets a lock on critical data structures and then
> gets suspended, those locks may not be relinquished. Then tutorial
> suggest we should instead use flag variables combined with wait() and
> notify().
>
> I donít see how that makes anything safer. Just as you can get a lock
> on critical data structure and then suspend a thread using suspend(),
> you can also get a lock on critical data structure and set a flag in
> such a way, that thread gets suspended ( via wait() ). In both cases
> result would be the same. So how is the latter safer? Itís just a
> different syntax, but same end result!


No, because wait releases the lock.

Arne

EJP 06-25-2008 12:32 AM

Re: I donít understand how new approach to suspending, resuming threads is any safer thanÖ
 
Srubys@gmail.com wrote:
> So how is the latter safer? Itís just a
> different syntax, but same end result!


Because Thread.wait() can be interrupted.

Neil Coffey 06-25-2008 02:36 AM

Re: I donít understand how new approach to suspending, resuming threads is any safer thanÖ
 
Srubys@gmail.com wrote:

> you can also get a lock on critical data structure and set a flag in
> such a way, that thread gets suspended ( via wait() ). In both cases
> result would be the same. So how is the latter safer? Itís just a
> different syntax, but same end result!


With wait(), as somebody mentioned, the thread can be interrupted,
and when it is interrupted it will continue execution at a well-
defined point (namely, wherever you've caught InterruptedException).
A crucial thing is that there's no way for a thread to
*die* while leaving synchronization locks held if you always let its
run() method end explicitly.

As far as I'm aware, this doesn't protect you from acquiring an
explicit Lock and then letting the thread die, though I must admit
I haven't really thought about it until now, for t'would be a most
crazy thing to do...

The bottom line is that you should be in control of how a thread exists/
is suspended and what happens to shared resources at those points.

Neil

Srubys@gmail.com 06-25-2008 09:44 PM

Re: I donít understand how new approach to suspending, resuming threads is any safer thanÖ
 
On Jun 25, 4:36 am, Neil Coffey <neil.cof...@french-linguistics.co.uk>
wrote:
> Sru...@gmail.com wrote:
> > you can also get a lock on critical data structure and set a
> > flag in such a way, that thread gets suspended ( via wait() ).
> > In both cases result would be the same. So how is the latter
> > safer? Itís just a different syntax, but same end result!

>
> With wait(), as somebody mentioned, the thread can be
> interrupted, and when it is interrupted it will continue
> execution at a well- defined point (namely, wherever you've
> caught InterruptedException).
> A crucial thing is that there's no way for a thread to
> *die* while leaving synchronization locks held if you always let
> its run() method end explicitly.



So if I understand your argument correctly, then in certain
situations when something unexpecting happens ( not necessarily due
to bad programming ) and thread A canít get out of suspend/wait state,
the ability of another thread to interrupt A is the only way thread A
will be able to releases a lock?
Is that all there is to it? Meaning, is that the main ( or even the
only ) reason why suspend() was deprecated?



> wait releases the lock.


So unlike wait(); suspend() doesnít release the lock on object?


>A crucial thing is that there's no way for a thread to
>*die* while leaving synchronization locks held if you always let
>its run() method end explicitly.

>As far as I'm aware, this doesn't protect you from acquiring an
>explicit Lock and then letting the thread >die,


But if a thread dies( even if via uncaught exception ), arenít locks
automatically released ( I assume by die you mean thread ceases to
exist )?


thank you

Arne VajhÝj 06-25-2008 11:58 PM

Re: I donít understand how new approach to suspending, resuming threads is any safer thanÖ
 
Srubys@gmail.com wrote:
> On Jun 25, 4:36 am, Neil Coffey <neil.cof...@french-linguistics.co.uk>
> wrote:
>> Sru...@gmail.com wrote:
>>> you can also get a lock on critical data structure and set a
>>> flag in such a way, that thread gets suspended ( via wait() ).
>>> In both cases result would be the same. So how is the latter
>>> safer? Itís just a different syntax, but same end result!

>> With wait(), as somebody mentioned, the thread can be
>> interrupted, and when it is interrupted it will continue
>> execution at a well- defined point (namely, wherever you've
>> caught InterruptedException).
>> A crucial thing is that there's no way for a thread to
>> *die* while leaving synchronization locks held if you always let
>> its run() method end explicitly.

>
> So if I understand your argument correctly, then in certain
> situations when something unexpecting happens ( not necessarily due
> to bad programming ) and thread A canít get out of suspend/wait state,
> the ability of another thread to interrupt A is the only way thread A
> will be able to releases a lock?
> Is that all there is to it? Meaning, is that the main ( or even the
> only ) reason why suspend() was deprecated?


No.

If it is suspended it can not be interrupted. And if it waiting
it already has released the lock.

>> wait releases the lock.

>
> So unlike wait(); suspend() doesnít release the lock on object?


Correct.

>> A crucial thing is that there's no way for a thread to
>> *die* while leaving synchronization locks held if you always let
>> its run() method end explicitly.
>> Ö
>> As far as I'm aware, this doesn't protect you from acquiring an
>> explicit Lock and then letting the thread >die,

>
> But if a thread dies( even if via uncaught exception ), arenít locks
> automatically released ( I assume by die you mean thread ceases to
> exist )?


They are.

Arne


All times are GMT. The time now is 04:59 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.