[concurrency-interest] A new Lock implementation: FileLock

Dawid Kurzyniec dawidk at mathcs.emory.edu
Tue Aug 30 13:18:40 EDT 2005


Gregg Wonderly wrote:

>
>
> Dawid Kurzyniec wrote:
>
>> 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. (...)

In the scenarios I outlined, accessor service would be exposed to 
exactly same issues, and I don't see how it is supposed to help. When do 
you start the accessor service? Who starts it? How do you make sure that 
you only have one instance running? What do you do when it crashes? How 
do you detect it crashed? In fact, in the IMAP server example in 
particular, if you look from the perspective of IMAP clients, the server 
can itself be considered an accessor service. After all, it allows 
clients to indirectly access shared files stored on the server host. 
Should I be implementing an accessor service using an accessor service? 
Where does it stop?

At some level, "distributed system" ends and the "local system" begins, 
and you simply have to assume that something is reliable - in this case, 
the local file system. Otherwise, multiphase commit is not going to help 
you either, because at some point it has to give green light to writing 
data to a file system, and if the file system crashes just at this 
moment, you end up with inconsistent data as well. You make Jini sound 
as a magic bullet that can somehow solve reliability issues in 
distributed systems which are known to be unsolvable without assumptions 
that are in fact stronger than those needed for a file lock to work 
reliably.

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

Again, there is no way around that. At some level, stuff gets written to 
the filesystem. If the accessor service, or a local resource manager 
involved in a distributed transaction, crashes during a filesystem 
operation, it leaves inconsistent data. If the data is left "locked", 
you have a stale lock - similarly in behavior to Thread.suspend in Java. 
But if you release the lock, you leave unprotected inconsistent data - 
like Thread.stop does. In either case, you need some error-recovery 
procedure; just restarting the crashed process won't suffice. At some 
level, you simply have to deal with that, possibly resorting to human 
intervention, because file systems are not transactional. File locks and 
renaming files as a "commit" are as good as it gets.

> The technical argument is that the Jini transactional services do 
> everything you need for a working distributed locking service.

And I claim that file locks are good for *non-distributed* shared 
filesystem access, keeping in mind that all systems are non-distributed 
at some level where they interact with the file system. Hence, again, 
the conclusion that file locks and distributed transaction managers are 
solutions to different problems :)

Side note. Download size of JRE 5.0: about 15 MB. Download size of Jini 
starter kit: over 11 MB. Not a huge difference. And note that the 
bulkiness of JRE is already considered a barrier to entry in some cases.

Regards,
Dawid



More information about the Concurrency-interest mailing list