Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jun 2004 19:20:41 -0600
From:      Stephen Hurd <shurd@sasktel.net>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Locking: kern/50827
Message-ID:  <20040630192041.1d9c5348.shurd@sasktel.net>
In-Reply-To: <20040628192935.GF5635@green.homeunix.org>
References:  <20040624174919.46160f9e.shurd@sasktel.net> <20040628192935.GF5635@green.homeunix.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> > Has anyone looked at this?  Does anyone have any comments?
> >
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/50827
> 
> I don't think you'll ever find anyone interested in file locking
> anymore. Since they're all advisory, anyway, you can just implement them
> at a higher level in your application.  BSD and System V IPC mechanisms
> already are very good building blocks here for system-scoped locks.

Hrm?  I'm sort of confused... file locking is still the best way of doing
erm... file locking.  A few points:

1) File locking works with any program using the file locking API. 
Hand-rolled implementations will only work with other programs which use
the same hand-rolled routines.
2) File locking works across NFS, so you aren't limited to the local
system.
3) There's no simple way of doing per-descriptor locks using BSD and SysV
IPC... ie: locks which are automatically released when the file descriptor
used to obtain the lock is released.  This also of course means programs
which core won't leave stale locks laying around.

Essentially, implementing locks at a higher level is alway more difficult,
usually more prone to problems, and in some cases introduces more overhead
than the rest of the program.

The only reason I can think of for implementing locks at a higher level is
for cross-platform code...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040630192041.1d9c5348.shurd>