Date: Thu, 17 Apr 2003 17:47:36 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com>, "Terry Lambert" <tlambert2@mindspring.com> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <001d01c304c6$60b13dd0$f001a8c0@davidw2k> References: <Pine.GSO.4.10.10304170519410.5432-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20 From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> To: "Terry Lambert" <tlambert2@mindspring.com> Cc: "David Xu" <davidxu@viatech.com.cn>; <freebsd-threads@freebsd.org> Sent: Thursday, April 17, 2003 5:24 PM Subject: Re: libpthread patch > On Thu, 17 Apr 2003, Terry Lambert wrote: >=20 > > 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. > >=20 > > I guess the next question is why thread-lending (ala NT, > > MACH, etc.) isn't supportable. >=20 > It might still be possible; it's just not as easy. >=20 > > > 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). > >=20 > > Is there a particular performance/other reason this is allowed? >=20 > 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). >=20 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=20 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. > --=20 > Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001d01c304c6$60b13dd0$f001a8c0>