Date: Thu, 5 Dec 1996 18:31:38 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: dyson@freebsd.org Cc: smp@csn.net, vanmaren@fast.cs.utah.edu, ccsanady@friley216.res.iastate.edu, peter@spinner.dialix.com, smp@freebsd.org Subject: Re: make locking more generic? Message-ID: <199612052331.SAA29433@hda.hda.com> In-Reply-To: <199612051834.NAA05328@dyson.iquest.net> from John Dyson at "Dec 5, 96 01:34:01 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > This is all part of the enormous problem of adding fine-grained > > > locking to an existing single-threaded kernel. > > > > yes, it will be a HUGE task to get it right! > > > That is the reason that I am kind-of asking which directions that you > are looking at. If you don't have anything in mind at the VFS/VM > levels, I will look at it from a reasonable viewpoint myself... This doesn't relate to multi-threading the VM system, but from the viewpoint of VM support for locks it would be good to permit associating a region with a lock that could be unmapped or mapped read-only based on the state of an unlocked / read-only / read-write lock. Related to the earlier points about driver data structures and reentrancy: I believe the driver data structures themselves end up being independent based on the interrupt source and present less of a locking issue than the kernel support routines that the drivers call. Single threading the entrance into the top half of a driver per-controller as was suggested should get things off the ground. Sorry if I'm too obvious - I'm pretty new to following this list. -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612052331.SAA29433>