Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Nov 1999 23:35:03 -0500
From:      "Daniel M. Eischen" <eischen@vigrid.com>
To:        Julian Elischer <julian@whistle.com>
Cc:        Matthew Jacob <mjacob@feral.com>, freebsd-arch@freebsd.org
Subject:   Re: Threads stuff
Message-ID:  <38377677.7AF35412@vigrid.com>
References:  <Pine.BSF.4.10.9911201853440.6767-100000@current1.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
> 
> On Sat, 20 Nov 1999, Matthew Jacob wrote:
> >
> > Sure- that's kernel stuff, but it doesn't really work much in the area I
> > would be interested, namely making interrupt and other kernel threads
> > (e.g., for CAM device inventory management) for all drivers that could use
> > them (an interrupt thread per interrupt entry point is not unreasonable),
> > replacing all spl type locking with mutex_init (based on device interrupt
> > levels) and mutex_enter/mutex_exit usages, perhaps replacing sleep/wakeup
> > which is a per-process thingie with cv_wait/cv_signal.. you know, that
> > kinda low level kernel I/O stuff- more nuts and bolts and less
> > theoretical. When the discussion gets around to these things and policies
> > about whether SMP safe and SMP-unsafe drivers can coexist, then I'll be
> > more than happy to waste everyone's time with my opinions.
> 
> But it's all inter-related.. The KSE allocator would be the same
> KSE allocator that would be used to innitially allocate KSEs for
> interrupt handling. (My secret agenda starts to show). My aim is to
> get the BSDI "lazily evaluated threads" interrupt scheme. however the
> threads they would be evaluating to would be the same KSEs that would
> be allocated to the User thread scheme..
> 
> "A thread is a thread is a thread"
> 
> Believe me my heart is in the "low level more nuts and bolts". I just see
> a convergence of needs here.
> 
> We certainly need someone to help with the KSEs and specifically the Mutexy
> stuff. That should be quite applicable to both ends..

There's some good articles on locking too.  Perhaps that should be
another topic on -arch ;-)

I agree with Matt and want to see mutex_enter, mutex_exit, cv_wait, cv_signal,
etc, as opposed to sleep/wakeup.  Count me in as wanting to help with "mutexy"
stuff as well as threads.

Dan Eischen
eischen@vigrid.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38377677.7AF35412>