A thread that can be interrupted before starting 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.
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().