On 23 Aug 1999, Ville-Pertti Keinonen wrote: > > g...@lemis.com (Greg Lehey) writes: > > > Again, if we have two concurrent transactions, we stand to gain money: > > the updated balance is likely not to know about the other transaction, > > and will thus "forget" one of the deductions. > > > Now I suppose you're going to come and say that this is bad > > programming, and advisory locking would do the job if the software is > > written right. Correct. You could also use the same argument to say > > that memory protection isn't necessary, because a correctly written > > program doesn't overwrite other processes address space. It's the > > The difference is that if a program has privileges to screw up > whatever you are protecting, it can do so even if you do have > mandatory locking, simply by functioning incorrectly when it does gain > access to the data. > > And even without otherwise incorrect behavior, if you have a program > that doesn't use any locking and another one that uses mandatory > locking to prevent races with the non-locking program, the mere > existence of the locking program does not prevent multiple non-locking > programs from generating similar conditions.
That's very odd, I thought the idea behind mandatory locking was to completely eliminate the possibility that a program could do what you're saying; all programs would *mandatorily* be forced to do locking to access the resource. It's the advisory locking that allows the scenario you paint. I think mandatory locking should exist, but only be available to root. If a program needs this, it must run with root privs, so that ordinary users cannot wedge the machine, but (as usual) root can shoot himself in the foot (traditional Unix methodology). > > (I'm not opposed to mandatory locking in principle, but I don't find > your reasoning very convincing.) > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
