What to do with an InterruptedException in Java

[Saham]

This from Brian Goetz:
https://www.ibm.com/developerworks/library/j-jtp05236/

The InterruptedException is for stopping a thread or exiting an application. If you catch an InterruptedException then release any resources that the thread has and finally call Thread.currentThread().interrupt() to notify the caller.

The article provides further details on how to make sure your threads play nice when your app or long-running task needs to quit.

 

[stricken]

Aaaaah... the sweet memory of that steaming pile of overly verbose synchronous goop called Java.

Node, Go, Python and Haskell says hello world (in much fewer lines btw)

 

[Saham]

I don't think the code is overly verbose ... it gives more levers for controlling the details. My IDE provides auto-complete to generate the standard code and then I get to tweak it as I like. The app I work on runs on 16-core systems so the threading has to be just right.

Anyway, our system architect made the decision to go with Java 5 years ago & we're too busy adding new features to re-implement the almost 2 million lines of code & get that tested thoroughly enough.

 

[_kabal_]

Nodejs....Python.....Cool story

Java does hello world in the same number of lines(5) as golang

 

[[)roi(]]

Aaaaah... the sweet memory of that steaming pile of overly verbose synchronous goop called Java.

Node, Go, Python and Haskell says hello world (in much fewer lines btw)

Leonardo da Vinci with a bucket of mud and a mop vs. YOU, ... yes tools matter; but simply sticking the "right" paint brush in someone's hands isn't a guarantee of success.

 

[[)roi(]]

This from Brian Goetz:
https://www.ibm.com/developerworks/library/j-jtp05236/

The InterruptedException is for stopping a thread or exiting an application. If you catch an InterruptedException then release any resources that the thread has and finally call Thread.currentThread().interrupt() to notify the caller.

The article provides further details on how to make sure your threads play nice when your app or long-running task needs to quit.

Not a clear cut topic; threading is a maelstrom of opinion, technique and scenario. As for technique there's many approaches to this problem, for example:

• POSIX Threads: is an execution model that exists independently from a language, as well as a parallel execution model. It allows a program to control multiple different flows of work that overlap in time.
• Target / Action: a design pattern in which an object holds the information necessary to send a message to another object when an event occurs.
• Callbacks / Completion Handlers: a callback is any executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at a given time.
• Promises & Futures: refer to constructs used for synchronizing program execution in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is yet incomplete.
• Functional Reactive Programming: is a programming paradigm for reactive programming (asynchronous dataflow programming) using the building blocks of functional programming (e.g. map, reduce, filter).
• Actor Model: is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent computation. In response to a message that it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may modify private state, but can only affect each other through messages (avoiding the need for any locks).
• Async / Await: allows an asynchronous, non-blocking method call to be performed in a similar way to an ordinary synchronous method call.
• Coroutines and Generator Functions: are components that generalize subroutines for non-preemptive multitasking, by allowing multiple entry points for suspending and resuming execution at certain locations.

It's likely I'm missing a few approaches, but it should be enough to appreciate there's no way to easily wrap up threading in a single article. Aside from Async / Await and Coroutines, all the techniques mentioned above are readily available for use in Java.

 

[Saham]

This from Brian Goetz:
https://www.ibm.com/developerworks/library/j-jtp05236/

Not a clear cut topic; threading is a maelstrom of opinion, technique and scenario. As for technique there's many approaches to this problem

I should have made it clear that this article from Brian Goetz was only about what to do with an InterruptedException when you're forced to deal with it, & how to play nice with this aspect of Java's way of terminating threads. It took me a very long time to find any useful info on this subject.

 

[bridgeburner]

An interesting concept is JCSP which is effectively a Java implementation of Tony Hoare's Communicating Sequential Processes. Its a pretty cool tool to eliminate some of the verbosity and clunkiness of Java threading. The library itself is largely built on top of Java's threading model, but its useful for gaining a solid understanding of concurrent systems and related concepts such as deadlock, livelock, starvation etc

 

[Saham]

Now I remember why the thread shutdown loomed so large ... some important clients had unreliable power at some sites so they were using a UPS which would trigger system shutdown if the battery power was running out. All the threads had to react quickly when interrupted and save their data.

 

[[)roi(]]

I should have made it clear that this article from Brian Goetz was only about what to do with an InterruptedException when you're forced to deal with it, & how to play nice with this aspect of Java's way of terminating threads. It took me a very long time to find any useful info on this subject.

Sure... FYI the JVM code for this hinges on Posix Threads, so challenges you encounter will be very similar those experienced with pThreads. As for the the other concurrency techniques; their approaches are quite different; specifically avoiding these scenarios.