From owner-freebsd-threads@FreeBSD.ORG Fri Jun 20 12:40:45 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 1C6EA37B401 for ; Fri, 20 Jun 2003 12:40:45 -0700 (PDT) Received: from rwcrmhc11.attbi.com (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87E1C43F75 for ; Fri, 20 Jun 2003 12:40:44 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <20030620194043013008rh0de>; Fri, 20 Jun 2003 19:40:44 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA58558; Fri, 20 Jun 2003 12:40:43 -0700 (PDT) Date: Fri, 20 Jun 2003 12:40:42 -0700 (PDT) From: Julian Elischer To: Igor Sysoev In-Reply-To: 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: Fri, 20 Jun 2003 19:40:45 -0000 On Fri, 20 Jun 2003, Igor Sysoev wrote: > On Fri, 20 Jun 2003, Julian Elischer wrote: > > > On Fri, 20 Jun 2003, Igor Sysoev wrote: > > > > > If we could sacrifice our current thread compatibility in 5.0-5.1 > > > then we could change kse_mailbox from > > > > > > struct kse_mailbox { > > > int km_version; /* Mailbox version */ > > > struct kse_thr_mailbox *km_curthread; /* Current thread */ > > > ... > > > > > > to > > > > > > struct kse_mailbox { > > > struct kse_thr_mailbox *km_curthread; /* Current thread */ > > > int km_version; /* Mailbox version */ > > > ... > > > > > > then x86's gs would still point to kse_mailbox, and gs:[0] would be > > > and TP pointer. Also we need to modify > > > > > > struct kse_thr_mailbox { > > > + void *tls; > > > ucontext_t tm_context; /* User thread context */ > > > ... > > > > > > And the static TLS must be allocated before kse_thr_mailbox. > > > > Yes. > > This is what I was thinking... > > I'm wrong, this scheme does not allow to use the 1:1 model in libkse > when kse_mailbox.km_curthread is always NULL. I think we can still have a value at kse_mailbox.km_curthread even for 1:1 type threads.. > > We can implement such scheme on x86: > > gs -> [ TP ] ---> [ TLS ] > [ struct kse_mailbox ] +-> [ struct kse_thr_mailbox ] > [ .km_curthread ] -+ > > When UTS would switch to the next thread it should set thread's TLS: > > kse_mailbox.km_curthread = NULL; > gs:[0] = next_thr_tls; > kse_mailbox.km_curthread = next_kse_thr_mailbox; yes and the last line is atomic.. But remember having a NULL curhtread pointer stops upcalls but it is not the ONLY thing that stops upcalls.. A flag TMF_NOUPCALLS (spelling?) in the mailbox will also inhibit any upcalls. 1:1 threads (BOUND) threads, (system scope threads?) set this bit, but they still can have a mailbox for other purposes. (e.g. setting mode flags and stuff). If you are talking about libthr when you say 1:1 then they have gs:0 pointing to an array of pointers each of which points to a thread structure.. (they have the same indirection, but there is no KSE mailbox at teh indirection point, just the pointer.) (in _setcurthread.c ) void *ldt_entries[MAXTHR]; (these are set to point to thread structures as they are needed and %gs:0 points to an entry in this array) There is a small race we must guard against when accessing TLS.. %gs-->KSE--->TLS however the thread can be preemted between any two machine instructions, and unless the TMF_NOUPCALLS bit is set, it may start executing again under a DIFFERENT KSE. this means that we can not do: lea gs:0, %esi movl (%esi),%esi to find the TLS as at teh time of the 2nd command, we may have been pre-empted and %gs may point to a different place.. HOWEVER ensuring that we get past teh gs and into the actual thread-specific stuff in one instruction, e.g. movl gs:0, %esi ;%esi now points to a thread-specific thing.. should get around this.. > > kse_mailbox can be accessed via gs register. On amd64 scheme is the same > except the use of fs register instead of gs. > > However on sparc64, ia64 and alpha TP is in the register but not > in the memory so we need introduce the new field tm_kse in kse_thr_mailbox > to find kse_mailbox: > > TP -> [ TLS ] > [ struct kse_thr_mailbox ] > [ .tm_kse ] ---> [ struct kse_mailbox ] > > > By the way how was kse_mailbox being found before gs register was used ? > > > Igor Sysoev > http://sysoev.ru/en/ > >