[concurrency-interest] A new Lock implementation: FileLock

Joshua Bloch jbloch at gmail.com
Sat Aug 27 14:21:23 EDT 2005


Folks,

Hi. I wrote a new java.util.concurrent.locks.Lock implementation
called FileLock.  Briefly, a FileLock instance is backed by a
java.nio.channels.FileLock as well as a
java.util.concurrent.locks.ReentrantLock.  It implements functionality
similarlar to ReentrantLock, but without the bells and whistles, and
it works across VMs as well as within a VM.

But there are problems:

(1) Perhaps the fundamental problem: if you're doing locking across
VMs, it's probably because you're protecting some shared persistent
resource.  If a VM holding a FileLock dies, the lock is automatically
dropped.  If the shared persistent resource is in an inconsistent
state, woe betide thee.

(2) I discovered that there is a bug in java.nio.channels.FileLock.
As a result, you get horrible, machine-dependent behavior if you try
to create multiple instances of my FileLock class in a single VM
backed by the same file.  On windows, your process hangs.  On Unix,
you don't get mutual exclusion among threads.  If
java.nio.channels.FileLock obeyed its spec, you'd get a nice exception
(OverlappingFileLockException).  I reported this bug today, but I
don't expect it to get fixed any time soon.

(3) If I were to implement condition variables in conjunction with
FileLock, Condition.signal would not work across VMs.  This would
violate the principle of least astonishment.  So, for now, I haven't
implemented condition variables (though it would be easy to do).

(4) People would use FileLocks across physical machines, using NFS
files.  This might work reliably.  Or it might not.  If it didn't,
they'd get angry at me.

Anyway, if you are so inclined, take a look at it and tell me what you
think.  When I first came up with the idea, I thought it might make a
nice addition to j.u.c, but now I'm not so sure.

            Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FileLock.java
Type: application/octet-stream
Size: 8186 bytes
Desc: not available
Url : /pipermail/attachments/20050827/50e21ae0/FileLock.obj


More information about the Concurrency-interest mailing list