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

Groups > comp.lang.java.programmer > #23107 > unrolled thread

Re: polling IRQs in a thread's code

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#23107 — Re: polling IRQs in a thread's code

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.

[toc] | [next] | [standalone]

#23111

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 );

[toc] | [prev] | [next] | [standalone]

#23114 — [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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#23119 — 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!

[toc] | [prev] | [next] | [standalone]

#23121 — 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

[toc] | [prev] | [next] | [standalone]

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

On Mon, 25 Mar 2013 08:43:13 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> 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

[toc] | [prev] | [next] | [standalone]

#23132 — 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.

[toc] | [prev] | [next] | [standalone]

#23122

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/

[toc] | [prev] | [next] | [standalone]

#23123 — [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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#23124 — 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/

[toc] | [prev] | [next] | [standalone]

#23125 — 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/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web