Implementing TLS: step 1

Terry Lambert tlambert2 at mindspring.com
Thu Jun 19 23:37:39 PDT 2003


Julian Elischer wrote:
> 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))

This adds the assumption that, following an involuntary context
switch, when the next quantum is allocated to the KSE, the thread
that was running under that KSE is the one which will be activated,
regardless of priority relative to other threads.  It further
assumes that the thread will not be migrated to another KSE (e.g.
on another CPU which is assigning quantum to the process, while
the KSE in question is the only one in the "runnable" state in
the process at the time of the assignment).

Neither of these are valid assumptions.  The first one breaks
already, in the current implementation, if you are not running
a hacked user space scheduler.

I don't think this is a reasonable direction to go.  Your own
suggestion that a second indirection is needed to get the
actual thread (and TLS context pointer) is correct, IMO.

-- Terry


More information about the freebsd-threads mailing list