Date: Mon, 23 Jun 2003 08:28:44 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: threads@freebsd.org Subject: Re: Implementing TLS: step 1 Message-ID: <Pine.GSO.4.10.10306230820280.10658-100000@pcnet5.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0306222322050.79545-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Jun 2003, Julian Elischer wrote: > On Sun, 22 Jun 2003, Daniel Eischen wrote: > > > 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. > > Firstly, I think that all threads should HAVE mailboxen, even if we > don't use them. If we are running in the UTS or the initial > 'thread' before getting a 'kse' then it would be an error to access TLS. > > Do you disagree? Nope :-) > > > 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. > > I think we should say that if there is no current thread there is no > Thread -specific data.... Right. It just forces libpthread to differentiate between critical regions when there is a thread and when there isn't. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10306230820280.10658-100000>