Java: When to use Interrupt vs flags?

Question

To indicate to a thread that it must "interrupt" its work Java provides a mechanism known as Interrupts:

public void run() {
    while(!Thread.interrupted()) {
        // Fazer algo
    }
}

// para interromper
minhaThread.interrupt();

That said, it is not uncommon to find code that does the same thing "on the nail" with a flag volatile:

private volatile boolean running = true;

public void stop() {
    running = false;
}

public void run() {
    while(running) {
        // Fazer algo
    }
}

// para interromper
minhaThread.stop();

When should I use each of these techniques?

Answer 1

The use of a flag volatile, as presented in the question, it brings no benefit beyond a feeling on the part of the developer to have in his hands the "control" of execution. :)

Interruptions

The Java Threads API has implemented a generic use flag to manage "paused thread interrupts".

If a thread is paused in a call to Object#wait(), Thread#join or Thread#sleep, the method interrupt() is able to "wake her up". In practice, it is as if there had been an error in the call to one of these methods and he launched the exception InterruptedException.

Certain input and output (I/O) operations may also be affected, for example those using InterruptibleChannel.

The interrupt flag implementation is native, so the JVM can use more optimized mechanisms for communication between threads.

Therefore, if used correctly, the API provides advanced mechanisms to stop a thread from running even when there are time-consuming operations being performed, such as file access and networking.

Interruptions and ties

Such a flag is also commonly used to interrupt ties, as in the question example.

The only danger in doing this is not controlling the status of the interrupt flag properly.

For example, if you treat the interruption exception:

public void run() {
    while(!Thread.interrupted()) {
        // Começa algo
        try {
            // Faz algo que pode lançar InterruptedException
        } catch (InterruptedException e) {
            log.error(e);
        }
        // Finaliza algo
    }
}

The code above will result in a noose infinite because capturing the exception clears the flag and the output condition of the loop will always be false!

Because of this, if there is need to catch such exception, in general is recommended that the interruption in the catch, thus:

public void run() {
    while(!Thread.interrupted()) {
        // Começa algo
        try {
            // Faz algo que pode lançar InterruptedException
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            log.error(e);
        }
        // Finaliza algo
    }
}

Since the exception treatment may be "hidden" within another method, some recommend, as a precaution, always calling the interrupt within a catch that captures such an exception.

Flag volatile

Manually controlling with a flag has some disadvantages, among which I consider the worst:

• Variable sharing required. Threads need to communicate directly, increasing coupling.
• Inability to interrupt queued threads.
• Developers who don’t understand the volatile. Some try to imitate the use and forget the modifier, which can lead to racing conditions and unexpected behaviors.

On the other hand, there are advantages to this approach:

• If the flag is not simply one boolean, that is, if there is any more complex object that is shared. For example, in the case of threads consuming a queue, the "flag" may be the queue is empty.
• Whether an arbitrary number of threads depends on the same flag.
• If no immediate interruption of the current thread iteration is desired. It may be, for example, that the goal is just to finish the loop, but any operation waiting for wait or join should continue until the end.
• The use of a flag in such a trivial loop is simpler to understand, compared to the API.

API confusing

Unfortunately, the Java interrupt control API is somewhat confusing. Compare the methods available:

• Thread.interrupt(): interrupts a thread. It should be called directly on an object, which can be the current thread (as in the example above) or some other thread, if you want to interrupt it. This method activates the interrupt flag.
• Thread.isInterrupted(): checks if the interrupt flag is active for a given thread. It should also be called in an object, which may be the current thread or another thread.
• Thread.interrupted(): returns the state of the interrupt flag and clears the flag. This is a static method of the class, so it is called without an object and always references the current thread.

The first two methods make a lot of sense, but the last one is somewhat strange, because once it is invoked it effectively clears the flag. this leads to unusual situations such as when a boolean expression is used in a if modifies the state and code below "see" other values.

Considerations

My suggestion is to use the API by default when this applies to the problem. If there is a more specific need, a manual solution is needed and there are no problems with this.

It’s not wrong to use a flag, but for a mature developer it’s important to learn how to use the Java API - or any language you use. Part of this is avoiding solutions ad hoc when possible.

Answer 2

Threads can go into standby mode and wait for a condition to continue. In the case of wait() this condition is a notify() or notifyAll(). In the case of a sleep() is simply that the time of "sleep" is elapsed.

Use interrupt() when you want to do the thread get out early in these modes of waiting, which will cause her to launch a InterruptedException.

On the other hand, use a flag the mechanism of interrupt() and check the interrupted status of thread when it is performing logical operations (it is not in standby mode) and you want it to end one of those operations and not continue the next ones. For example, if she is recording a list of files and you want her to stop when completing the recording of one of the files, without continuing to record the next ones.

Care should be taken with the method used to check the status of interrupted, because although the isInterrupted() does not clear flag status, other methods like interrupted() clean.

There is a use for the volatile in multithreading, but I confess that my knowledge is incomplete and I do not know why it is being used in this case. I believe it is not necessary in the scenario I described.

Answer 3

I understand that things are a little different!

To use interrupt it is necessary that within your method run throw a InterruptedException, so that when calling the interrupt this bid to Exception.

The cases that the InterruptedException must be implemented:

1. java.lang.Object#wait()
2. java.lang.Object#wait(long)
3. java.lang.Object#wait(long, int)
4. java.lang.Thread#sleep(long)

An example of how to stop a method run through the interrput :

public void run() {
        int pt = 0;
        try {
            while(true){
                System.out.println("ActionInterrupt {"+pt+"}");
                Thread.sleep(123L);
                pt++;
            }
        } catch (InterruptedException e) {
        // VAI CAIR AQUI, QUANDO CHAMAR O INTERRUPT!
            e.printStackTrace();
        }
    }

With the flag, there’s no need! It’s simpler and more direct!

I don’t need the Exception to stop the activity!

Completion:

If your Thread not launch a InterruptedException, then the flag should be used.

Follow an example!

Answer 4

My experience

• Your project is simple.
• Few threads
• Few routines

So we can consider such a scenario as any well-implemented solution serves. Context, I participated in a project where parallel processing was the main requirement.

Any of these solutions adopted or proposed there does not meet.

• First item high complexity
• Big flags, tags and object states issues
• It is very much up to you programmer to do the code (parallel processing control).
• Second join 1, 2, 3, different frameworks, jsf, Quartz, Jbossseam and a Weblogic server for example.
• Hibernate, transactions and IOC.
• Little experience, lack of time, people walking everywhere, all lost.

This will never work.

Solution:

Use a thread pool controller:

• Threadpoolexecutor (for example)
• Master transactions
• Parallel processing (which you can run in parallel)
• Code blocks protected, synchronized (should not synchronize but have multiple instances, but sometimes this is not possible)
• Complete control of transaction cycles
• Complete IOC control (if used in the project)
• If possible use thread pool of the framework itself, they are usually good.

In itself these are recommendations that serve for some project manager or analyst, even for programmers in general.