From owner-freebsd-threads@FreeBSD.ORG Thu Jun 19 15:36:14 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 D85D337B401 for ; Thu, 19 Jun 2003 15:36:14 -0700 (PDT) Received: from rwcrmhc11.attbi.com (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3934743FAF for ; Thu, 19 Jun 2003 15:36:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <20030619223613013008susoe>; Thu, 19 Jun 2003 22:36:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA50226; Thu, 19 Jun 2003 15:36:13 -0700 (PDT) Date: Thu, 19 Jun 2003 15:36:11 -0700 (PDT) From: Julian Elischer To: Marcel Moolenaar In-Reply-To: <20030619220008.GA1273@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org Subject: Re: Implementing TLS: step 1 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, 19 Jun 2003 22:36:15 -0000 On Thu, 19 Jun 2003, Marcel Moolenaar wrote: > On Thu, Jun 19, 2003 at 02:50:45PM -0700, Julian Elischer wrote: > > > > Libthr has the advantage that the register used for identifying the > > current thread can be set DIRECTLY at the thread control block, where > > libkse will (probably) require a single indirection. (by which I mean > > that the register will point to the control structure for the Virtual > > CPU that is running (KSE) and that in turn will have a pointer to the > > thread that is currently running. > > On ia64, the runtime specification dictates that the TP registers > points to the TLS. How the threads implementation relates this to > the thread control structure (or other control structures) is up to > the implementation. If libkse is ported to ia64, this will have to > be the case as well. Hence the thread pointer will *not* point to > the KSE. An indirection will be used to point from the TLS to the > KSE. > > There is no other way. There is always "another way". It's just whether it is worth following it.. What happens when there is no thread.. (e.g. the UTS (User Thread Scheduler) is running and has not selected a thread to run? Basically in libKSE there is what the kernel calls a thread, which is interpretted in userspace as a virtual CPU, and this is used to run user level threads. The kernel sets the thread-pointer register upcorrectly according to which of these "kernel visible threads" is running. This is a legitimate use of the thread pointer register as far as I see. In 1:1 (libthr) the two things are the same and it stops there. Under M:N, while the kernel's thread is running in the UTS there is no userland thread selected to be running on it, but the kernel still thinks it is running a thread. So from the kernel's (and other external) point of view, the KSE/VCPU is a thread. Only that thread itself knows that it is switching between different userland contexts. The thread register is set by the kernel according to which of the 'threads' it sees is about to be run. It doesn't see the userland threads and knows nothing aboyut them so it is physically incapable of setting the register to point to them. (though it COULD save and restore the value for threads that have enterred the kernel I guess, (blindly hoping that they make sense)) BTW what are the official register designations for ia64 i.e. what is reserved for what? Where is the doc that describes this? > > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net >