Date: Fri, 20 Jun 2003 12:40:42 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Igor Sysoev <is@rambler-co.ru> Cc: threads@freebsd.org Subject: Re: Implementing TLS: step 1 Message-ID: <Pine.BSF.4.21.0306201141480.57806-100000@InterJet.elischer.org> In-Reply-To: <Pine.BSF.4.21.0306202226410.26177-100000@is>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0306201141480.57806-100000>