Implementing TLS: step 1

[Daniel Eischen]

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