Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Aug 1999 08:28:40 -0600
From:      Wes Peters <wes@softweyr.com>
To:        Christopher Masto <chris@netmonger.net>
Cc:        Garance A Drosihn <drosih@rpi.edu>, "Daniel C. Sobral" <dcs@newsguy.com>, Greg Lehey <grog@lemis.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Matthew Dillon <dillon@apollo.backplane.com>, FreeBSD Hackers <hackers@FreeBSD.ORG>, FreeBSD Committers <cvs-committers@FreeBSD.ORG>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Subject:   Re: Mandatory locking?
Message-ID:  <37C2AC18.28A9DE08@softweyr.com>
References:  <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <37C174F5.2D8AEEB1@newsguy.com> <v04210103b3e7529e5859@[128.113.24.47]> <19990823223645.A14001@netmonger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Christopher Masto wrote:
> 
> > The thing about well-intentioned but incorrect locking code is that
> > it will appear to work fine, until it trips over the one code path
> > where it forgets to lock some file that it should have locked.  And
> > even then, the code will "work" just fine, until multiple processes
> > are accessing that file at the same time.
> >
> > I think it is appropriate for an operating system to provide an option
> > such that *it* (the system) will enforce the locking, and not have to
> > trust that all code-paths in all programs will do the right thing
> > WRT advisory locking.
> 
> Dunno about that.. if you're using advisory locking, you know to say
> "lock the file, then read the data, do your calculation, write it out,
> and unlock".  This manditory locking sounds like an invitation for
> disaster.  "I don't need to pay attention to the details because
> the kernel will take care of it for me."

Wrong paradigm.  Look at it from the lockers standpoint: "Even if other
processes don't do locking, they won't be able to screw me because I've
locked the critical part of the file."

> Actually, I don't really understand the paradigm.  Two processes need
> to safely update a file, so one of them aquires a mandatory lock, and
> the other.. uh.. just blocks trying to open the file? 

No, the locks are not per-file.  You can lock multiple arbitrary byte ranges.
Any file trying to write (shared lock) and/or read (exclusive lock) will be
blocked until the lock is released.

-- 
            "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                         Softweyr LLC
http://softweyr.com/                                           wes@softweyr.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37C2AC18.28A9DE08>