Implementing TLS: step 1

[Julian Elischer]

On Fri, 20 Jun 2003, Igor Sysoev wrote:

> On Fri, 20 Jun 2003, Julian Elischer wrote:
> 
> > On Fri, 20 Jun 2003, Igor Sysoev wrote:
> > 
> > > If we could sacrifice our current thread compatibility in 5.0-5.1
> > > then we could change kse_mailbox from
> > > 
> > >         struct kse_mailbox {
> > >            int                     km_version;     /* Mailbox version */
> > >            struct kse_thr_mailbox  *km_curthread;  /* Current thread */
> > >            ...
> > > 
> > > to
> > >      
> > >         struct kse_mailbox { 
> > >            struct kse_thr_mailbox  *km_curthread;  /* Current thread */
> > >            int                     km_version;     /* Mailbox version */
> > >            ...
> > > 
> > > then x86's gs would still point to kse_mailbox, and gs:[0] would be
> > > and TP pointer.  Also we need to modify
> > > 
> > >      struct kse_thr_mailbox {
> > > +          void              *tls;
> > >            ucontext_t        tm_context;     /* User thread context */
> > >            ...
> > > 
> > > And the static TLS must be allocated before kse_thr_mailbox.
> > 
> > Yes.
> > This is what I was thinking...
> 
> I'm wrong, this scheme does not allow to use the 1:1 model in libkse
> when kse_mailbox.km_curthread is always NULL.

I think we can still have a value at kse_mailbox.km_curthread even for
1:1 type threads..

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

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



> 
> kse_mailbox can be accessed via gs register. On amd64 scheme is the same
> except the use of fs register instead of gs.
> 
> However on sparc64, ia64 and alpha TP is in the register but not
> in the memory so we need introduce the new field tm_kse in kse_thr_mailbox
> to find kse_mailbox:
> 
> TP -> [ TLS                    ]
>       [ struct kse_thr_mailbox ]
>       [                .tm_kse ] ---> [ struct kse_mailbox ]
> 
> 
> By the way how was kse_mailbox being found before gs register was used ?
> 
> 
> Igor Sysoev
> http://sysoev.ru/en/
> 
>