From owner-freebsd-hackers Fri Jun 7 21:46:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA06470 for hackers-outgoing; Fri, 7 Jun 1996 21:46:54 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA06430; Fri, 7 Jun 1996 21:46:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA05318; Fri, 7 Jun 1996 21:40:08 -0700 From: Terry Lambert Message-Id: <199606080440.VAA05318@phaeton.artisoft.com> Subject: Re: The -stable problem: my view To: michaelh@cet.co.jp (Michael Hancock) Date: Fri, 7 Jun 1996 21:40:08 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, grog@lemis.de, hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD-current@FreeBSD.org In-Reply-To: from "Michael Hancock" at Jun 8, 96 11:25:24 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Gee, if only you had top level reader/writeer locks that were multiple > > reader/single writer to serialize groups of changes over a set of 'n' > > files. 8-). > > Maybe you should provide an example of how multiple reader/single writer > locks can parrallelize a section of kernel code while keeping things > consistent. The developers can then maybe extrapolate the idea to > improving the CVS commit process in a very *cheap* yet effective way. > > Geeks hate words like (enforce|policy) when it comes to areas that affect > their working style. But a cool technical idea..... I think I did provide an example of this -- I don't rememebr if it was on the SMP list or on -hackers, now, though. It had to do with setting up hierarchical lock management for per processor memory pools that are filled from a system pool, or drained to the system pool when they hit a high "pages free" watermark. For a non-SMP ecample, you could visualize reeentering the FS on multiple searches of the same directory. If I set a reader lock on a block, it would prevent block compaction, but only in that block, so that creates would not change the block offset while the block is being read. For a block in which a create/delete were taking place, a writer lock would be asserted, which would block reading until the write had completed. This would allow any number of readers to enter a block, as long as there was no writer, but only one writer to enter the block (when there were no readers -- the "IW" (Intention to Write lock) assertion is made on the block, and subsequent readers are prevented from entering, --but may assert an "IR" -- (Intention to Read lock) to prevent multiple writers from starving the readers. The "IW" is converted to a "W" when all of the readers have "drained" out of the locked segment. After the write completes, the "W" is deasserted, and the "R" blocks can be serviced. When no more "IR"'s remain to be converted to "R" (since the conversion is global and simultaneous for all IR's, since they are not exclusive), then any outstanding IW assertions are allowed to complete, and again, any "W" is blocked pending reader drain. For a CVS implementation, it would be relatively easy to exclusively lock the "want lock" list" and process it linearly in the "unlock" process, with a one second (or 5 second) file modification "poll" by all waiters. Perhaps, ideally, you would want something like: [ ... ] # # cvs_lock_read_wait - shell function to wait for read lock # cvs_lock_read_wait() { while true do cvs lock read if test "$?" = "0" then echo "reader lock acquired" exit 0 fi echo "waiting..." sleep 5 done } # # cvs_help - extended help after real help, or args + -H # cvs_help() { case "$1x" in x) $REALCVS -H ; ST=$? echo " lock Lock command"; exit $ST;; lock) echo "Usage: cvs lock [read | write ]"; exit 1;; unlock) echo "Usage: cvs unlock"; exit 1;; *) $REALCVS -H $*; ST=$?; exit $ST;; else $REALCVS $* fi } # # cvs_default - all other (non-lock, non-help) commands # cvs_default() { $(REALCVS) $* } [ ... ] This all being part of the "cvs" shell script that replaces the real cvs program, which has been renamed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.