From owner-freebsd-threads@FreeBSD.ORG Thu Apr 17 09:21:02 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 87A3237B401; Thu, 17 Apr 2003 09:21:02 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4A7F43F75; Thu, 17 Apr 2003 09:21:01 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0064.cvx21-bradley.dialup.earthlink.net ([209.179.192.64] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196C8C-0002H0-00; Thu, 17 Apr 2003 09:21:01 -0700 Message-ID: <3E9ED420.41E89DDA@mindspring.com> Date: Thu, 17 Apr 2003 09:19:44 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Xu References: <001d01c304c6$60b13dd0$f001a8c0@davidw2k> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a412eac2785dba42fded3c9d55f46d4d73350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Daniel Eischen 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 16:21:02 -0000 David Xu wrote: > > > > 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. So dual-map the pages containing them, into both kernel and user space, and be done with it. Add a seperate read-only mapping to a read/write mapping, and point to one in the other, if you're concerned about protecting some kernel data from the user space process. This doesn't need to be so hard. -- Terry