A thread that can be interrupted before starting

Question

As per the Java documentation:

Interrupting a thread that is not alive need not have any effect.

Particularly, interrupting a thread between the call to start() and the invocation of run() has no effect.

So I wrote a Thread which can be interrupted even before it started, so that the interrupted state is communicated once it started:

/**
 * A thread that can be interrupted before actually starting (that is between the moment {@link
 * #start} is called and {@link #run} is invoked.
 */
public final class InterruptableThread extends Thread {
    private final AtomicBoolean mInterrupted = new AtomicBoolean(false);
    private final Object mLock = new Object();
    private final AtomicBoolean mStarted = new AtomicBoolean(false);

    public InterruptableThread(Runnable runnable) {
        super(runnable);
    }

    @Override
    public void run() {
        synchronized (mLock) {
            mStarted.set(true);
            if (mInterrupted.get()) {
                super.interrupt();
            }
        }

        super.run(); // Let the original runnable handle the interruption by itself.
    }

    @Override
    public void interrupt() {
        synchronized (mLock) {
            mInterrupted.set(true);
            if (mStarted.get()) {
                super.interrupt();
            }
        }
    }
}

It seems safe to me, although the AtomicBoolean are maybe not required. But because we're dealing with multithreading here, another point of view is welcome.

I need this in a library with start() and stop() methods which look like:

public void start() {
    synchronized (mStartStopLock) {
        myThread = new InterruptableThread(myRunnable);
        myThread.start();
    }
}

public void stop() {
    synchronized (mStartStopLock) {
        myThread.interrupt();
        myThread.join();
    }
}

As you can see, despite the lock, if start() and stop() are called immediately one after another, nothing guarantees that interrupt() will have effect on the thread if it's a regular Java Thread. That's important because the Runnable uses the interrupted status for stopping itself.

Answer 1

Review

• A Java Thread's default behavior is:

  A thread interruption ignored because a thread was not alive at the time of the interrupt will be reflected by this method returning false.

• Changing the default behavior of interruption in a thread's lifecycle seems a bit tricky to me. I don't think you should override exising methods to change their specification when dealing with such common and wellknown threading constructs.
• Instead, I would create 2 new methods, requestRun() and requestInterruption() to clearly indicate different functionality from run() and interrupt().
• If you do decide to override run() and interrupt() make sure to clearly state in the Javadoc that the specification of these methods has changed.
• InterruptableThread is an unfortunate name, since Thread is also interruptible. A better name would be PreemptiveInterruptibleThread.
• Since you have atomic booleans, perhaps you could check the value before taking the lock, in order to mitigate access to the locks. There is a possible race condition though. You can read more about Double-checked locking here. Is your question implementation Idempotent?
• If the atomic booleans are only used inside this lock, they could be replaced with ordinary booleans.
• I like the fact everything that could be made final, has been declared final.
• I do believe there still is a race condition after releasing the lock in run() and before calling super.run().