[concurrency-interest] A new Lock implementation: FileLock

Gregg Wonderly gregg at cytetech.com
Tue Aug 30 12:12:25 EDT 2005



Dawid Kurzyniec wrote:
>> My point is that a solution already exists. 
> 
> Only, to a different problem.

I appreciate this feeling.  But, I am not sure that it's well founded, yet.

> Scenarios where I would use file locking are those where I would
> synchronize access to shared files stored in the very same filesystem.
> For instance, suppose I am developing an e-mail client that caches
> messages in ${user.home}/Mail. Then I need some means of protecting data
> from mangling when the user launches two clients simultaneously. The
> same goes if I am developing an e-mail server, since the user may open
> multiple sessions simultaneously, which can e.g. move/delete files on
> the server. Or, suppose I want to make sure that only a single instance
> of an executable can be running on a host (e.g. if it is a system-level
> service). These are well-known (for decades) and legit use cases for
> file locking, in which I would be out of my mind to deploy a distributed
> transaction manager.

In many of these cases I would use an accessor service, today, instead of a distributed locking mechanism.  This would 
allow a single place to be in control of access, and multithreading issues could be controlled exactly in the place 
where that control was needed.  Sure we used to use locks, because everything was on the same machine there were little 
library functions that were part of various packages that you needed to use to do locking with those applications.  The 
problem is that all of them did something differently, and this made interworking more difficult.  A standard locking 
service allows you to tie the operations of multiple applications together for a new application.

Advisory file locking is straight forward to use.  When we used link(2) to create advisory locks in unix, we got into 
problems with stuck locks when processes crashed.  We would next add signal handlers to try and catch the process death 
and remove all locks.  Then, the errant users found out about SIGKILL, and found that they could wreak havoc on things. 
  So we added flock() so that the lock was really implemented in the kernel.  That is a locking service implementation! 
  Now, everyone goes through the same implementation, doing the same thing.  Josh is talking about taking one such 
implementation of a file locking service that is distributed via NFS.  I'm suggesting that it would be even better to 
take the next step and just use something that already exists, which provides a lot of additional features that aren't 
afterthought addons.

> The bottom line is that EVERY technology, be it a hammer, Jini, or file
> locking, has its domain of applicability. Claiming that one technology
> can solve all world's problems is naive. At least, stick to the issue at
> hand, and confine yourself to precise, technical, non-vague,
> non-hypothetical, non-tutoring, non-red-herring and non-philosophical
> arguments.

Dawid, I'm sorry that you feel like my argument was overbearing or incorrectly placed.  My personal experience with 
software development over the past 20+ years has taught me that cutting corners and creating a minimal implementation 
for my own use, just to get started "cheaper" is not really the best thing.

The technical argument is that the Jini transactional services do everything you need for a working distributed locking 
service.  Do they do it optimally, or exactly the way you might implement it with ignorance to prior arts, in a new 
application?  Probably not.  But, the foundation is there to improve on.  The JERI stack is plugable for providing more 
optimal transports of data while maintaining a Java platform API approach to programming.

Gregg Wonderly


More information about the Concurrency-interest mailing list