[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Implementing TLS: step 1
- Subject: Implementing TLS: step 1
- From: julian at elischer.org (Julian Elischer)
- Date: Thu Jun 19 15:36:17 2003
On Thu, 19 Jun 2003, Marcel Moolenaar wrote:
> On Thu, Jun 19, 2003 at 02:50:45PM -0700, Julian Elischer wrote:
> > Libthr has the advantage that the register used for identifying the
> > current thread can be set DIRECTLY at the thread control block, where
> > libkse will (probably) require a single indirection. (by which I mean
> > that the register will point to the control structure for the Virtual
> > CPU that is running (KSE) and that in turn will have a pointer to the
> > thread that is currently running.
> On ia64, the runtime specification dictates that the TP registers
> points to the TLS. How the threads implementation relates this to
> the thread control structure (or other control structures) is up to
> the implementation. If libkse is ported to ia64, this will have to
> be the case as well. Hence the thread pointer will *not* point to
> the KSE. An indirection will be used to point from the TLS to the
> There is no other way.
There is always "another way". It's just whether it is worth following
What happens when there is no thread.. (e.g. the UTS (User Thread
Scheduler) is running and has not selected a thread to run?
Basically in libKSE there is what the kernel calls a thread, which is
interpretted in userspace as a virtual CPU, and this is used to
run user level threads. The kernel sets the thread-pointer register
upcorrectly according to which of these "kernel visible threads"
is running. This is a legitimate use of the thread pointer register as
far as I see. In 1:1 (libthr) the two things are the same and it stops
Under M:N, while the kernel's thread is running in the UTS
there is no userland thread selected to be running on it, but the kernel
still thinks it is running a thread. So from the kernel's (and other
external) point of view, the KSE/VCPU is a thread. Only that thread
itself knows that it is switching between different userland contexts.
The thread register is set by the kernel according to which
of the 'threads' it sees is about to be run.
It doesn't see the userland threads and knows nothing aboyut them so it
is physically incapable of setting the register to point to them.
(though it COULD save and restore the value for threads that have
enterred the kernel I guess, (blindly hoping that they make sense))
BTW what are the official register designations for ia64
i.e. what is reserved for what? Where is the doc that describes this?
> Marcel Moolenaar USPA: A-39004 marcel_(_at_)_xcllnt_(_dot_)_net
Visit your host, monkey.org