Date: Mon, 23 Aug 1999 22:59:10 -0400 (EDT) From: Chuck Robey <chuckr@picnic.mat.net> 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: <Pine.BSF.4.10.9908232256550.49952-100000@picnic.mat.net> In-Reply-To: <19990823223645.A14001@netmonger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Aug 1999, 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." > > 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? How does it > know it's not the first one? It means that if user A puts data in (and follows locking procedure correctly) then he doesn't have to worry that user B might not be following correct locking procedure, because user B is mandatorily forced to follow the procedure. There isn't any added sloppiness, just a guarantee that if one user locks a file, no other rogues can get into it while the lock exists. ---------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---------------------------+----------------------------------------------- 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?Pine.BSF.4.10.9908232256550.49952-100000>