Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #23122

Re: polling IRQs in a thread's code

Path csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From Robert Klemme <shortcutter@googlemail.com>
Newsgroups comp.lang.java.programmer
Subject Re: polling IRQs in a thread's code
Date Mon, 25 Mar 2013 23:15:54 +0100
Lines 67
Message-ID <arc0kvFn6snU1@mid.individual.net> (permalink)
References <thread-20130324233549@ram.dialup.fu-berlin.de> <kio1a2$onu$1@dont-email.me>
Mime-Version 1.0
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-Trace individual.net VznCLiQVX8LtTjStWWxiUQ5BawiDh9qZyO5AO40KI1M9Gf49s=
Cancel-Lock sha1:6hu5PD5DnuVEdVBSFdZ0sB/gbQM=
User-Agent Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
In-Reply-To <kio1a2$onu$1@dont-email.me>
X-Antivirus avast! (VPS 130325-2, 25.03.2013), Outbound message
X-Antivirus-Status Clean
Xref csiph.com comp.lang.java.programmer:23122

Show key headers only | View raw


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/

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: polling IRQs in a thread's code markspace <markspace@nospam.nospam> - 2013-03-24 16:14 -0700
  Re: polling IRQs in a thread's code markspace <markspace@nospam.nospam> - 2013-03-24 21:54 -0700
    [OT] Re: polling IRQs in a thread's code Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-03-25 08:43 -0400
      Re: [OT] Re: polling IRQs in a thread's code markspace <markspace@nospam.nospam> - 2013-03-25 13:27 -0700
        Re: [OT] Re: polling IRQs in a thread's code Lew <lewbloch@gmail.com> - 2013-03-25 13:44 -0700
      Re: [OT] Re: polling IRQs in a thread's code Gene Wirchenko <genew@telus.net> - 2013-03-26 11:41 -0700
        Re: [OT] Re: polling IRQs in a thread's code paul.cager@gmail.com - 2013-03-26 12:03 -0700
  Re: polling IRQs in a thread's code Robert Klemme <shortcutter@googlemail.com> - 2013-03-25 23:15 +0100
    [OT] Re: polling IRQs in a thread's code Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-03-25 19:58 -0400
      Re: [OT] Re: polling IRQs in a thread's code Robert Klemme <shortcutter@googlemail.com> - 2013-03-26 08:03 +0100
        Re: [OT] Re: polling IRQs in a thread's code Robert Klemme <shortcutter@googlemail.com> - 2013-03-26 08:07 +0100

csiph-web