Implementing TLS: step 1

[Julian Elischer]

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
> 
>