[concurrency-interest] A new Lock implementation: FileLock

Joshua Bloch jbloch at gmail.com
Tue Aug 30 12:41:41 EDT 2005


> Joshua Bloch wrote:
> > Jini is a large, complex AP consisting of 60+ packages!
> There are many parts of Jini which you don't need for such things.
> > java.util.concurrency.locks.Lock has 6 methods.
> I understand this thought, but it in fact uses the whole JVM implementation which is many more lines of code than Jini.

That is utterly irrelevant.  Who cares how many lines of code there
are in the JVM *implementation*?  We are talking about the conceptual
weight of an interface.  The target audience for this class already
knows the java.util.concurrent.locks.Lock *interface*, so the marginal
conceptual weight of this implementation is pretty close to zero.  The
audience does not know Jini, and the marginal conceptual weight to
learn it is large.

> One example might be that you ran out of space on the file system.  Half of the data made it to disk, the other half is
> still pending, or lost.  But, the file system is actively aquiring new space, and you'd really like to let the failed
> writer finish its job, before letting other writers put their data in there.  However, at some point, you want progress
> to be made.  If the releasing process actually exited when the write failed because it has a bug, you could use a
> distributed lease to finally expire the access lock unconditionally and move on with some type of cleanup.

Typically you create a new file, and atomically replace the old one by
changing the name of the new one.  If you run out of space creating
the new one, the old one never changes.  This is what I did in
java.util.prefs. It is crude but effective.

This is the last I will say on this subtopic; you may have the last
word if it pleases you.


More information about the Concurrency-interest mailing list