On Sun, May 27, 2007 at 09:51:10AM +0100, David Howells wrote:
> J. Bruce Fields <[email protected]> wrote:
> > So if I request a write lock while holding a read lock, my request will
> > be denied?
>
> At the moment, yes. Don't the POSIX and flock lock-handling routines in the
> kernel normally do that anyway?
No, they'd upgrade in that case.
> > This is a little strange, though--if there's somebody waiting for a
> > write lock on an inode (because somebody else already holds a read lock
> > on it), that shouldn't block requests for read locks.
>
> That depends on whether you want fairness or not.
Neither posix nor flock locks delay a lock because of pending
conflicting locks. SUS, as I read it, wouldn't allow that.
> Allowing read locks to jump the queue like this can lead to starvation
> for your writers.
If you want fairness the best that you can do is to ensure that when
more than one pending lock can be applied, the one that has been waiting
longest will be chosen. But you can't make all such lock requests wait
for a lock that hasn't even been applied yet.
You can contrive examples of applications that would be correct given
the standard fcntl behavior, but that would deadlock on a system that
didn't allow read locks to jump the queue in the above situation. I
have no idea whether such applications actually exist in practice, but
I'd be uneasy about changing the standard behavior without inventing
some new kind of lock.
--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
