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).