From owner-freebsd-threads@FreeBSD.ORG Sun Jun 22 16:35:27 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 2D29637B401 for ; Sun, 22 Jun 2003 16:35:27 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8269843FB1 for ; Sun, 22 Jun 2003 16:35:26 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5MNZKXh028805; Sun, 22 Jun 2003 19:35:20 -0400 (EDT) Date: Sun, 22 Jun 2003 19:35:20 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer 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 Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2003 23:35:27 -0000 On Fri, 20 Jun 2003, Julian Elischer wrote: > > On Fri, 20 Jun 2003, Igor Sysoev wrote: > > > > > 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). Yes, but we don't always have a current thread, so this method doesn't work for all cases. > 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.. Since libpthread doesn't always have a current thread, we can't rely on this. -- Dan Eischen