Re: polling IRQs in a thread's code
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/