libpthread patch

[David Xu]

----- Original Message ----- 
From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
To: "Terry Lambert" <tlambert2 at mindspring.com>
Cc: "David Xu" <davidxu at viatech.com.cn>; <freebsd-threads at freebsd.org>
Sent: Thursday, April 17, 2003 5:24 PM
Subject: Re: libpthread patch


> On Thu, 17 Apr 2003, Terry Lambert wrote:
> 
> > Daniel Eischen wrote:
> > > The critical section is to prevent the thread from being
> > > swapped out by the kernel and sent to another KSE.  That's
> > > it; it's not meant to do the same thing as locking.
> > > There's per-kse stuff that needs to be accessed that
> > > isn't correct if the thread gets run on another KSE,
> > > regardless of whether or not a lock protects it.
> > 
> > I guess the next question is why thread-lending (ala NT,
> > MACH, etc.) isn't supportable.
> 
> It might still be possible; it's just not as easy.
> 
> > > If it wasn't possible for the kernel to send completed
> > > threads from one KSE to another (within the same KSE
> > > group), we probably wouldn't need critical sections
> > > (at least as currently implemented).
> > 
> > Is there a particular performance/other reason this is allowed?
> 
> I dunno.  The original Jasone Evans paper didn't allow this, but
> the Anderson SA paper did (although our version of KSE's is a bit
> different than SA).
> 

Because there is no benefit for kernel side, whether you use one
completed list per-ksegrp or one completed list per-upcall context,
there is always competion between threads trying to export their 
contexts, so using one completed list is simple way to go, if we
use completed list per-upcall context, there is other things we
would worry about.

> -- 
> Dan Eischen