Re: Findbugs and locks?

Lew wrote:
Jeff Higgins wrote:
if (n < lockArray.length) {
ReentrantReadWriteLock rrwl = lockArray[n];
WriteLock lock = rrwl.writeLock();
try {
lock.lock();
// do some disk I/O
} finally {
lock.unlock();
}
}
}

Is there a chance that lock.lock() would fail?

If so, would lock.unlock() cause any harm?

The usual pattern for resource acquisition and release with try-finally is

resource.acquire();
// break flow on acquire() failure
try
{
...
}
finally
{
resource.release();
}

That way the release() only occurs if the acquire() succeeds. Moving the acquire() into the try{} means that the release() will occur even if acquire() fails. This is how Knute coded it, and I don't see why his way caused a warning.

Well, double oops then. You're right, I'm too quick with the send button.

Still produces no bug reports.

import java.io.IOException;
import java.util.concurrent.locks.ReentrantReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock;

public class SSCCE {

static ReentrantReadWriteLock lockArray[];
static {
lockArray =
new ReentrantReadWriteLock[5];
for (int i=0; i<lockArray.length; i++)
lockArray[i] = new ReentrantReadWriteLock();
}

static void method(int n) throws IOException {

WriteLock lock = lockArray[n].writeLock();
lock.lock();
try {
// do some disk I/O
} finally {
lock.unlock();
}
}

public static void main(String[] args) {}
}



I would be more comfortable if Knute's way didn't cause any warnings, because I don't understand it either. However, I'm unfamiliar with Findbugs (although many recommend it very highly).

.

Quantcast