Why do blocking library methods often respond to interruption by calling static interrupted() instead of instance method isInterrupted()?

Question

Consider the following code from java.util.concurrent.locks.AbstractQueuedSynchronizer as one of the many examples of the idea presented in the title:

1258    public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout) throws Interrupted Exception {
1259        if (Thread.interrupted())
1260            throw new InterruptedException();
1261        return tryAcquireShared(arg) >= 0 ||
1262            doAcquireSharedNanos(arg, nanosTimeout);
1263    }

Why do most blocking library methods respond to interruption by calling the static method Thread.interrupted() instead of instance method isInterrupted() . Calling the static method also clears the interrupted status so if even the task handling code swallows the InterruptionException , there is no way for the callers to get to know about the interrupted status other than

Answer 1

It is always true that if you catch an InterruptedException, the interrupted flag has already been cleared. The exception itself is your signaling mechanism at that point. The catcher is required to either re-enable the flag or take care directly that the thread moves to a close.