Implementing TLS: step 1
Daniel Eischen
eischen at vigrid.com
Mon Jun 23 05:28:52 PDT 2003
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
More information about the freebsd-threads
mailing list