I don’t understand how new approach to suspending, resuming threads is any safer than…

S

Srubys

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
 
A

Arne Vajhøj

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
 
N

Neil Coffey

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
 
S

Srubys

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
 
A

Arne Vajhøj

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.
So unlike wait(); suspend() doesn’t release the lock on object?
Correct.


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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top