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

Discussion in 'Java' started by Srubys@gmail.com, Jun 25, 2008.

  1. Guest

    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
    , Jun 25, 2008
    #1
    1. Advertising

  2. Arne Vajhøj Guest

    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
    Arne Vajhøj, Jun 25, 2008
    #2
    1. Advertising

  3. EJP Guest

    wrote:
    > So how is the latter safer? It’s just a
    > different syntax, but same end result!


    Because Thread.wait() can be interrupted.
    EJP, Jun 25, 2008
    #3
  4. Neil Coffey Guest

    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
    Neil Coffey, Jun 25, 2008
    #4
  5. Guest

    On Jun 25, 4:36 am, Neil Coffey <>
    wrote:
    > 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
    , Jun 25, 2008
    #5
  6. Arne Vajhøj Guest

    wrote:
    > On Jun 25, 4:36 am, Neil Coffey <>
    > wrote:
    >> 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
    Arne Vajhøj, Jun 26, 2008
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeffrey Hiess

    How can I "peek" at the keyboard without suspending?

    Jeffrey Hiess, Nov 26, 2003, in forum: C Programming
    Replies:
    11
    Views:
    714
    Irrwahn Grausewitz
    Dec 2, 2003
  2. Maciej
    Replies:
    1
    Views:
    656
    Thomas Hawtin
    Oct 27, 2006
  3. Replies:
    8
    Views:
    1,186
  4. Ethan
    Replies:
    4
    Views:
    516
    Kevin McMurtrie
    Jun 30, 2010
  5. Jean G.
    Replies:
    4
    Views:
    124
    Robert Klemme
    Mar 13, 2010
Loading...

Share This Page