Date: Fri, 7 Jun 1996 21:40:08 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: terry@lambert.org, jkh@time.cdrom.com, grog@lemis.de, hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD-current@FreeBSD.org Subject: Re: The -stable problem: my view Message-ID: <199606080440.VAA05318@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.93.960608111806.14546B-100000@parkplace.cet.co.jp> from "Michael Hancock" at Jun 8, 96 11:25:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606080440.VAA05318>