Doing interruptible calls

When doing interruptible calls (calls that throw an InterruptedException), try to do the actions the modify the state of the object after this call, or try to leave object in a invalid state before doing that call (or do some cleanup yourself). If you don’t, objects could be left in an invalid state, and not usable anymore because its behavior could be undefined. This could lead to problems in threads using the same object, and this is not something you want (especially in general purpose concurrency structures used in an enterprise environment).

example:

  public E take() throws InterruptedException {
        mainLock.lockInterruptibly();

        try {
            while (ref == null)
                refAvailableCondition.await();

            lendCount++;
            return ref;
        } finally {
            mainLock.unlock();
        }
    }

The ‘mainLock.lockInterruptibly()’ and the ‘refAvailableCondition.await()’ both are interruptible and done before the state of the object is modified (lendCount++)

The example below shows the the example that doesn’t leave to object in a valid state when it is interrupted.

public E take() throws InterruptedException {
        mainLock.lockInterruptibly();

        try {
            lendCount++;           
            while (ref == null)
                refAvailableCondition.await();

            return ref;
        } finally {
            mainLock.unlock();
        }
    }

Alternative

If you can’t guarantee that the state is valid before executing the interruptible call, it is better to use an uninterruptible version of that call if it is available. The downside of uninterrubtible calls, is that the calling thread can’t be interrupted while waiting. In case of an application server shutdown, it could lead to shutdown/redeployment issues because the application doesn’t shut down (something I witnessed last week).

Although the checked nature of the InterruptedException can be a serious pain, doing interrupted calls is not trivial, and forcing you to deal with interrupted exceptions, forces you to think about it.

Advertisements

3 Responses to Doing interruptible calls

  1. Dave says:

    A pet peeve, but the call to “lockInterruptably” needs to be inside the try block, and the unlock call only called if the lock succeeds. Otherwise, if an exception is thrown after the lock and before the try, the lock will never be cleared. This can only happen in case of a JVM error or Thread.stop, so some may suggest I’m being overly paranoid, but when it comes to multi-threading I don’t believe it’s actually possible to be overly paranoid.

  2. pveentjer says:

    Hi Dave,

    as far as I know the recommended idiom for lock usage, is obtaining the lock outside the try/finally block.

    See the idiom example in the following documentation:
    http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html

  3. Tim Peierls says:

    lockInterruptibly() should not be called inside the try block. If IE is thrown, there would be a call to unlock() without holding the lock.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: