polling IRQs in a thread's code

Discussion in 'Java' started by Stefan Ram, Mar 24, 2013.

  1. Stefan Ram

    Stefan Ram Guest

    I am new to multithreading in Java. In a thread's code, I write:

    void run()
    { if( irq() )cleanup(); else
    { firstStep();
    if( irq() )cleanup1(); else
    { secondStep();
    ...

    The user can request the thread to end using a GUI button.
    The thread has to check often whether the user has requested
    this, and then has to stop.

    Now, all the thread's code is messed up with polling the
    status of the user request, before each and every other action.
    Writing and maintaining the code is more difficult. I cannot
    simply write

    void run()
    { firstStep();
    secondStep();
    ...
    cleanup(); }

    but have to write the code as above.

    Is this the usual way to proceed? Or can I simplifiy this somehow?
     
    Stefan Ram, Mar 24, 2013
    #1
    1. Advertising

  2. Stefan Ram

    Arne Vajhøj Guest

    On 3/24/2013 6:45 PM, Stefan Ram wrote:
    > I am new to multithreading in Java. In a thread's code, I write:
    >
    > void run()
    > { if( irq() )cleanup(); else
    > { firstStep();
    > if( irq() )cleanup1(); else
    > { secondStep();
    > ...
    >
    > The user can request the thread to end using a GUI button.
    > The thread has to check often whether the user has requested
    > this, and then has to stop.
    >
    > Now, all the thread's code is messed up with polling the
    > status of the user request, before each and every other action.
    > Writing and maintaining the code is more difficult. I cannot
    > simply write
    >
    > void run()
    > { firstStep();
    > secondStep();
    > ...
    > cleanup(); }
    >
    > but have to write the code as above.
    >
    > Is this the usual way to proceed? Or can I simplifiy this somehow?


    Trying to affect the thread from another thread is known to
    cause some problems.

    So testing inside the code is common.

    I would prefer a more common coding convention though.

    public void run() {
    ...
    if(stopflag) { }
    ...
    if(stopflag) { }
    ...
    if(stopflag) { }
    ...
    if(stopflag) { }
    ...
    }

    Arne
     
    Arne Vajhøj, Mar 24, 2013
    #2
    1. Advertising

  3. Stefan Ram

    markspace Guest

    On 3/24/2013 3:45 PM, Stefan Ram wrote:
    >
    > Is this the usual way to proceed? Or can I simplifiy this somehow?
    >


    Yes and no. First, I wish you would not use IRQ as your method name.
    Interrupt ReQuest is a hardware thing, and we don't have access to those
    from within the Java API.

    Second, I'd use interrupt(). It's the usual way of asking that a thread
    stop. Many routines in the Java API already check for the interrupt
    flag for you, which releaves you of some of the burden for testing.
    Likewise, wait() and similar fuctions also test for interrupts even when
    the thread isn't running, something you would be hard pressed to do.

    Third, your code could be structured a little better.


    void run()
    {
    if( irq() ) {
    cleanup();
    return;
    }
    firstStep();
    if( irq() ) {
    cleanup1();
    return;
    }
    secondStep();
    if( irq() ) {
    cleanup3();
    return;
    }
    ...

    I hope you see the pattern. Don't use cascading if-else. Just return
    from the run() method, it's cleaner. (Several of your braces appeared
    to be unbalanced when I corrected the code.) There's probably better
    ways of handling the clean-up code, but without more knowledge of what
    you are doing, it's hard to say.

    Lastly, look at java.util.concurrent.Executor and other frameworks in
    the concurrent package. They provide a lot of support for mulithreading.

    P. S. Get Java Concurrency In Practice. It's just about required for
    working with concurrency in Java.
     
    markspace, Mar 24, 2013
    #3
  4. In article <-berlin.de>,
    -berlin.de (Stefan Ram) wrote:

    > The user can request the thread to end using a GUI button.
    > The thread has to check often whether the user has requested
    > this, and then has to stop.


    Also consider SwingWorker<T,V>. You can publish intermediate
    results from within your implementation of doInBackground() and
    reliably update the GUI from process(), which executes on the EDT.
    This related example also illustrates using cancel():

    <https://sites.google.com/site/drjohnbmatthews/randomdata>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
     
    John B. Matthews, Mar 25, 2013
    #4
  5. Stefan Ram

    markspace Guest

    On 3/24/2013 7:57 PM, John B. Matthews wrote:

    > Also consider SwingWorker<T,V>.


    That's an excellent point, I completely spaced on the GUI part of his
    question. If GUI = Swing, then SwingWorker is an excellent solution to
    many problems.

    Also, SwingWorkers can be put in executors, and since it returns a
    Future, there's a convenient Future#cancel() method to kill the thing
    (which does use Thread#interrupt as I suggested earlier).
     
    markspace, Mar 25, 2013
    #5
  6. Stefan Ram

    Roedy Green Guest

    aOn 24 Mar 2013 22:45:47 GMT, -berlin.de (Stefan Ram)
    wrote, quoted or indirectly quoted someone who said :

    > Is this the usual way to proceed? Or can I simplifiy this somehow?


    You probably do not have to call your code as frequently as you think.
    Once in each loop is probably sufficient, and even then only the
    middle loops.

    Perhaps you can hide the test in some frequently used code, and throw
    an exception.

    I second the suggestion of getting Java Concurrency In Practice
    http://mindprod.com/book/9780321349606.html for sources
    --
    Roedy Green Canadian Mind Products http://mindprod.com
    Every method you use to prevent or find bugs leaves a residue of subtler
    bugs against which those methods are ineffectual.
    ~ Bruce Beizer Pesticide Paradox
     
    Roedy Green, Mar 25, 2013
    #6
  7. Stefan Ram

    markspace Guest

    On 3/24/2013 4:14 PM, markspace wrote:

    >
    > void run()
    > {
    > if( irq() ) {
    > cleanup();
    > return;
    > }



    I posted this, and I didn't much like it when I posted, and now I'm
    pretty sure it's rubbish, as they say on the other side of the Atlantic.
    SwingWorker got me thinking about better ways to do this.


    void run() {
    try {
    // tons o' stuff
    } catch( InterruptedException ex ) {
    // clean up
    }
    }

    The trick now is to check for an interrupt often enough. If you're
    publishing data periodically with the SwingWorker#publish method, that
    might be a good place to check. However you might want to check more
    often as well. Either way, throwing an exception seems much easier and
    cleaner at the top level than manually breaking your code into discreet
    sections.

    If you have very complicated clean-up code, you might have to package
    the clean-up into discreet chunks so it can be executed by the top level
    clean-up code.

    class MyTask implements Runnable { // or SwingWorker
    private Runnable cleanup;
    public void run() {
    try {
    a();
    b();
    c();
    } catch( InterruptedException ex ) {
    if( cleanup != null )
    cleanup.run();
    }
    }
    private void a() {
    cleanup = new CleanupA();
    //... do stuff, then when done, reset cleanup
    cleanup = null;
    }
    private class CleanupA implements Runnable {
    public void run() {
    // vacuum and dust
    }
    }
    private void b() {
    // etc.
    }
    private void c() {
    // etc.
    }
    }

    That seems cleaner to look at, at least for what's written there.

    If you do use Runnable, don't overlook this simple transform to get a
    more modern version.

    Future<X> future = new FutureTask( myTask, x );
     
    markspace, Mar 25, 2013
    #7
  8. Stefan Ram

    Eric Sosman Guest

    [OT] Re: polling IRQs in a thread's code

    On 3/25/2013 12:54 AM, markspace wrote:
    > [...]
    > Either way, throwing an exception seems much easier and
    > cleaner at the top level than manually breaking your code into discreet
    > sections.


    From http://www.merriam-webster.com/dictionary/discreet

    Definition of DISCREET
    1 : having or showing discernment or good judgment
    in conduct and especially in speech : prudent;
    especially : capable of preserving prudent silence
    2: unpretentious, modest <the warmth and discreet
    elegance of a civilized home — Joseph Wechsberg>
    3: unobtrusive, unnoticeable <followed at a discreet
    distance>

    See also http://www.merriam-webster.com/dictionary/discrete

    Coming attractions: "loose" and "lose" ;-)

    --
    Eric Sosman
    d
     
    Eric Sosman, Mar 25, 2013
    #8
  9. Stefan Ram

    Stefan Ram Guest

    Stefan Ram, Mar 25, 2013
    #9
  10. Stefan Ram

    markspace Guest

    Re: [OT] Re: polling IRQs in a thread's code

    On 3/25/2013 5:43 AM, Eric Sosman wrote:
    > On 3/25/2013 12:54 AM, markspace wrote:
    >> [...]
    >> Either way, throwing an exception seems much easier and
    >> cleaner at the top level than manually breaking your code into discreet
    >> sections.

    >
    > From http://www.merriam-webster.com/dictionary/discreet


    Curse you, English language! I'll get you yet!
     
    markspace, Mar 25, 2013
    #10
  11. Stefan Ram

    Lew Guest

    Re: [OT] Re: polling IRQs in a thread's code

    markspace wrote:
    > Eric Sosman wrote:
    >> From http://www.merriam-webster.com/dictionary/discreet

    >
    > Curse you, English language! I'll get you yet!


    Worse, "discretion" comes from "discreet", not "discrete".

    --
    Lew
     
    Lew, Mar 25, 2013
    #11
  12. On 25.03.2013 00:14, markspace wrote:
    > On 3/24/2013 3:45 PM, Stefan Ram wrote:
    >>
    >> Is this the usual way to proceed? Or can I simplifiy this somehow?

    >
    > Yes and no. First, I wish you would not use IRQ as your method name.
    > Interrupt ReQuest is a hardware thing, and we don't have access to those
    > from within the Java API.
    >
    > Second, I'd use interrupt(). It's the usual way of asking that a thread
    > stop. Many routines in the Java API already check for the interrupt
    > flag for you, which releaves you of some of the burden for testing.
    > Likewise, wait() and similar fuctions also test for interrupts even when
    > the thread isn't running, something you would be hard pressed to do.


    That can also be viewed as a downside: you loose control over when the
    process may be interrupted. If you only want to allow for interruption
    at certain steps in the process then interrupt() might actually be unusable.

    > Third, your code could be structured a little better.


    Another structure could be:

    private final List<Task> tasks = ...
    private volatile boolean run;

    public void run() {
    run = true;

    for (final Task t : tasks) {
    t.execute();

    if (!run) {
    cleanup();
    return;
    }
    }
    }

    or even

    public void run() {
    run = true;

    for (final Task t : tasks) {
    if (run) {
    t.execute();
    }
    else {
    t.ignore();
    }
    }
    }

    > P. S. Get Java Concurrency In Practice. It's just about required for
    > working with concurrency in Java.


    +1

    Kind regards

    robert


    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Mar 25, 2013
    #12
  13. Stefan Ram

    Eric Sosman Guest

    [OT] Re: polling IRQs in a thread's code

    On 3/25/2013 6:15 PM, Robert Klemme wrote:
    >[...]
    > That can also be viewed as a downside: you loose control over when the
    > process may be interrupted.[...]


    Elsethread I wrote

    > Coming attractions: "loose" and "lose" ;-)


    .... and on the principle of "Never threaten what you're not
    prepared to do," I guess my hand is forced.

    From http://www.merriam-webster.com/dictionary/loose

    Definition of LOOSE
    transitive verb
    1a: to let loose (see 1 loose): release
    b: to free from restraint
    2: to make loose : untie <loose a knot>
    3: to cast loose : detach
    4: to let fly : discharge
    5: to make less rigid, tight, or strict : relax
    intransitive verb
    : to let fly a missile (as an arrow) : fire

    See also http://www.merriam-webster.com/dictionary/lose

    Coming attractions: "then" and "than" :-(

    (Aside: Of the few languages I know, English is by far the
    most idiosyncratic, anti-systemic, and downright perverse.
    Toddlers' brains are said to be "wired" for learning language;
    an adult whose wiring has fallen away and who yet manages to
    learn English, even imperfectly, has my admiration and no
    little of my awe.)

    --
    Eric Sosman
    d
     
    Eric Sosman, Mar 25, 2013
    #13
  14. Re: [OT] Re: polling IRQs in a thread's code

    On 26.03.2013 00:58, Eric Sosman wrote:
    > On 3/25/2013 6:15 PM, Robert Klemme wrote:
    >> [...]
    >> That can also be viewed as a downside: you loose control over when the
    >> process may be interrupted.[...]

    >
    > Elsethread I wrote
    >
    > > Coming attractions: "loose" and "lose" ;-)


    LOOL

    > Coming attractions: "then" and "than" :-(


    You could throw "thin" in the mix. ;-)

    > (Aside: Of the few languages I know, English is by far the
    > most idiosyncratic, anti-systemic, and downright perverse.
    > Toddlers' brains are said to be "wired" for learning language;
    > an adult whose wiring has fallen away and who yet manages to
    > learn English, even imperfectly, has my admiration and no
    > little of my awe.)


    :)

    Cheers

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Mar 26, 2013
    #14
  15. Re: [OT] Re: polling IRQs in a thread's code

    On 26.03.2013 08:03, Robert Klemme wrote:
    > On 26.03.2013 00:58, Eric Sosman wrote:
    >> On 3/25/2013 6:15 PM, Robert Klemme wrote:
    >>> [...]
    >>> That can also be viewed as a downside: you loose control over when the
    >>> process may be interrupted.[...]

    >>
    >> Elsethread I wrote
    >>
    >> > Coming attractions: "loose" and "lose" ;-)

    >
    > LOOL


    Without wanting to reduce my part in this I believe there is a certain
    chance that pure reading of your "announcement" primed my mind to sneak
    in tooo many o's... *chuckle*

    Cheers

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Mar 26, 2013
    #15
  16. Re: [OT] Re: polling IRQs in a thread's code

    On Mon, 25 Mar 2013 08:43:13 -0400, Eric Sosman
    <> wrote:

    >On 3/25/2013 12:54 AM, markspace wrote:
    >> [...]
    >> Either way, throwing an exception seems much easier and
    >> cleaner at the top level than manually breaking your code into discreet
    >> sections.

    >
    > From http://www.merriam-webster.com/dictionary/discreet
    >
    > Definition of DISCREET
    > 1 : having or showing discernment or good judgment
    > in conduct and especially in speech : prudent;
    > especially : capable of preserving prudent silence
    > 2: unpretentious, modest <the warmth and discreet
    > elegance of a civilized home — Joseph Wechsberg>
    > 3: unobtrusive, unnoticeable <followed at a discreet
    > distance>
    >
    >See also http://www.merriam-webster.com/dictionary/discrete
    >
    >Coming attractions: "loose" and "lose" ;-)


    And "prescribe" and "proscribe".

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Mar 26, 2013
    #16
  17. Stefan Ram

    Guest

    Re: [OT] Re: polling IRQs in a thread's code

    On Tuesday, 26 March 2013 18:41:18 UTC, Gene Wirchenko wrote:
    > On Mon, 25 Mar 2013 08:43:13 -0400, Eric Sosman
    >
    > >Coming attractions: "loose" and "lose" ;-)

    >
    > And "prescribe" and "proscribe".


    You are pedant's.
     
    , Mar 26, 2013
    #17
    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. Roz Lee

    Re: connection polling

    Roz Lee, Jul 10, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    1,295
  2. amit kumar via .NET 247

    regarding polling through thread

    amit kumar via .NET 247, Apr 5, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    327
    Scott Allen
    Apr 5, 2005
  3. paswenson

    Asserting IRQs

    paswenson, Jan 23, 2008, in forum: VHDL
    Replies:
    0
    Views:
    571
    paswenson
    Jan 23, 2008
  4. Giovanni Azua
    Replies:
    4
    Views:
    789
    Giovanni Azua
    Sep 29, 2011
  5. Rolando
    Replies:
    3
    Views:
    86
Loading...

Share This Page