From owner-freebsd-threads@FreeBSD.ORG Thu Apr 17 02:45:55 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D42237B401 for ; Thu, 17 Apr 2003 02:45:55 -0700 (PDT) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA88F43F75 for ; Thu, 17 Apr 2003 02:45:53 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HLDQQR7L; Thu, 17 Apr 2003 17:31:32 +0800 Message-ID: <001d01c304c6$60b13dd0$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" , "Terry Lambert" References: Date: Thu, 17 Apr 2003 17:47:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 09:45:55 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "Terry Lambert" Cc: "David Xu" ; 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