Java Thread Interruption in a general sense

user_13841360 0
Viewed 120

One of the most suggested ways to pause a thread is to extend the Runnable interface by adding a pause() method:

interface RunnablePausable extends Runnable {
    public void pause();
}

This never made sense to me since you don't actually want to pause the runnable but the Thread that runs it, in the same way you start/interrupt a Thread, not a Runnable.

A more elegant approach: since the interrupt() functionality is well built-in and supported by multiple methods, what if we interrupt() a Thread not just to terminate it, but for a general request instead (like you would interrupt a CPU, in a way)? And then let the Runnable handle this specific request

As an example: interrupt() the thread and, instead of straight up terminating it, handle its request to pause, stop, resume, or do anything else you like.

Not sure if this makes sense.

Something like this:

public void run() {
    try {
        //...
    } catch (InterruptedException ie) {     //interrupted
        if (i_wanted_to_pause) {            //manage request
            //wait
        }
        if (i_wanted_to_stop) {
            //return
        }
        if (any_other_request) {
            //handle it
        }
    }
}

And:

public void run() {
    if (Thread.currentThread().isInterrupted()) {   //interrupted
        if (request_to_pause) {                     //manage request
            //wait
        }
        if (request_to_stop) {
            //return
        }
        if (any_request) {
            //handle it
        }
    }
}

Now the problem is: how to make a specific request to the interrupted thread?

How can I communicate my request to the interrupted thread, as if was meant to stop, pause, or do anything else?

Ideas:

  • Subclass InterruptedException into InterruptedExceptionStop and InterruptedExceptionPause (no idea how I can throw them)
  • Create a separate object containing the request. Don't know what would be the best way to achieve this without over-complicating things
  • Other?
multithreading java
1 Answers
  1. Yes, as @markspace said in the comments, there is no any practical reason to request a thread to do things like pause/resume/etc at any moment(?).

The thread is just the calculation in general meaning. You know, there is the following popular pattern for CPU intensive executions:

ExecutorService es = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());

This means a thread ~= a CPU core. See a thread as a CPU core here. I believe this is an idiomatic view - a long-living sequential calculation, a conveyor. Do you think there should be a way to pause a CPU core by a user? To stop the conveyor by a button stuck to each box on it? I don't think so. So, if you want to prevent CPU from the calculation, just don't ask it to do the calculation. A classical example - Job/Task Queue baked with a thread and a BlockingQueue. You split your calculation into several jobs to consume them to the queue. If you don't consume new ones (optionally clear the queue), your thread is 'paused' naturally on take(). The same for IO, until you are OK to burn CPU with completely non-blocking solutions. With your code, you also have to take care about 3rd party things/objects you use in your run() to don't get them accidentally broken after the interruption, since it's true that "interruption == termination" is a commonplace semantically.

Another possible argument against the approach is mostly an architectural one. Runnable, Callable are examples of the IoC (Inversion of Control) pattern. But we introduce a control/execution management method into them, and this smells IMO.

If you had explained what was the specific problem you were trying to address, we would suggest a more suitable, more idiomatic than RunnablePausable approach.

  1. Now, why do I like the question. It's inspiring to me when developers think about their things so deeply. It's nice when they invent something, even if these are their own homebrewed Continuations and Schedulers:) It may be an instructive game/experiment.
user_33197250
Related