Implementing TLS: step 1
Julian Elischer
julian at elischer.org
Sun Jun 22 23:26:16 PDT 2003
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?
>
> > 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....
>
> --
> Dan Eischen
>
>
More information about the freebsd-threads
mailing list