From: ara.t.howard@...
Date: 2006-10-25T06:57:58+09:00
Subject: Re: File#flock as a cross-process mutex

On Wed, 25 Oct 2006, Francis Cianfrocca wrote:

> On 10/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>> 
>> On Wed, 25 Oct 2006, Francis Cianfrocca wrote:
>> 
>> > Has anyone wrapped up File#flock so it can used as a
>> platform-independent
>> > cross-process mutex? (I'm getting tired of writing the same code into
>> every
>> > app I do.) Or does anyone have a better idea?
>> 
>> can you elaborate?  do you need to yield the resource and re-aquire it?
>
>
> Most of the time I want to make sure only one process is running in a
> particular directory at a time. And if another one tries to start up, it
> should get an exception. And I also want it to be completely behaved in the
> presence of both hangs and crashes. Sometimes I do need to yield and
> re-acquire, but I'm not looking for condition variables, just mutual
> exclusion.

you might look at this

   http://rubyforge.org/frs/?group_id=1024&release_id=3473

   http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/

   http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/README

   http://codeforpeople.com/lib/ruby/lockfile/lockfile-1.4.0/doc/rlock.help

i use it all over the place in production across many nfs mounted node to
ensure only one node runs a particular process.  one of the nice features it
has is that it auto-detects stale locks.  the basic process works like this:

   - once we aquire a lock we start a thread (or process - it's configurable)
     to touch the file every so often (configurable)

   - if a process hangs or dies the lock becomes stale.  this will be noticed
     by a process trying to aquire the lock - someone will eventually steal the
     lock if it becomes too stale and then timeout for a while because i'm
     paranoid like that.  this timeout is also configurable.

the whole process is atomic, even on nfs, and of course works on local
filesystems to.  you can use via the api like so

   lockfile = Lockfile.new 'my.lock'

or run existing programs without modification like so

   rlock my.lock --rlock-option -- some_old_program --some_old_program-option

so it's easy to integrate into an existing system.

note that this is file based, not flock based so, while the performance isn't
that of flock, it's not bad either.  though i'm guessing from your use case
you are locking too often...

regards.

-a
-- 
my religion is very simple.  my religion is kindness. -- the dalai lama