🚀 go-pugleaf

In article <423@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>> From: Jeff Anton, Ingres Group <ucbvax!anton>
>>
>> A DBMS would be well off with three (3) levels of locks [...]  shared,
>> update, and exclusive. [...]  If you think you might have to change some
>> data in a file you get an update lock.  [...]  If you do have to change
>> the data you raise the lock to exclusive and wait until all the shared
>> locks go away.  Know what else goes away?  Deadlock.
>
>	I'm not sure I follow.  I don't see how the update lock is anything
>more than a hint that you might want an exclusive lock later.  Like all
>hints (vadvise for example), this may improve efficiency, but I don't see
>how it really changes anything in the end.  In particular, how does this
>eliminate deadlocks (and why doesn't the 2-stage 4.2 flock)?

	Note that an update lock conflicts with other update locks but
allows shared locks.  This avoids the possible deadlock case of two
shared locks tring to promote to exclusive locks as only update locks
should promote to exclusive, and there can only be one update lock.

>	Since we're on the subject, there's something I don't understand
>about the 4.2 flock(2) call.  As I understand it, having a shared lock
>guarantees that the file can't change beneath you.  But when you update
>your shared lock to an exclusive one, "this results in the previous lock
>being released and the new lock applied (POSSIBLY AFTER OTHER PROCESSES
>HAVE GAINED AND RELEASED THE LOCK)" [my emphasis].  This doesn't make
>sense; you poke around in the data base to figure out what you want to do
>and then, just before you are ready to write your changes, you give
>somebody else a chance to write theirs?  Doesn't that mean that you then
>have to go back and re-compute your whole update?
>
>	I can see how *not* giving others a shot when you upgrade a lock
>might lead to deadlocks (which would answer my previous question nicely,
>thank you).  As I read the manual, though, it just doesn't make sense.  Can
>somebody tell me what I'm missing (if anything)?

	The funny behavior of flock avoids the deadlock problem
I mentioned above, with dangerous consequences.  If two shared locks
tried to promote to exclusive, you have a problem.  If I understand
the internals of 4.3 on the vax correctly, once all shared locks
dissappear the proc which first requested the exclusive lock should
get it and then the next.  To protect yourself, you should re-read
whatever data you had durring the shared lock before you do your
write.  This just slows things down more and intrduces all kinds of
problems includeing concurancy conflict which is the problem
locks are specifically used to avoid.  (You're right on both counts.)

>> [talking about reliability and limitations of the file system]
>> But for the banks and the purests, we're working on what may be a way
>> around the problems.  I'm not sure enough right now to publicize yet.
>
>	If there are problems with the file system, why can't you just open
>up a raw disk and implement your own like was done for testing the 4.2 F.S.
>under a 4.1 kernel?  I don't see any way to get around the write-behind
>strategy in the block I/O system, but at least you can make multi-volume
>files if you want.  You could even implement shadow pages and volumes (to
>keep "the banks and the purests" happy) in the user-level file system
>routines.  Cpu cycles *are* cheaper than HSC-50's, aren't they? :-)

I should have said "an elegant solution."  (i.e. new)
-- 
C knows no bounds.
					Jeff Anton
					U.C.Berkeley
					Ingres Group
					ucbvax!anton
					anton@BERKELEY.EDU