Re: thread-ready ABIs

["Kevin D. Kissell" <kevink@mips.com>]

Tue, Jan 22, 2002 at 01:18:03PM +0100, Kevin D. Kissell wrote:
> > I think that the problem is complicated by the fact that
> > there may be a many->many mapping of kernel threads
> > (and CPUs) to user-land threads.  In that case, no single
> > low-memory address can be correct for all kernel threads.
> > However, since every kernel thread should have its own
> > stack segment, it would appear to me that having a
> > variable "under" the stack would satisfy the need for
> > per-kernel-thread storage at a knowable location.
> > I suspect that there is a second-order problem in that
> > the base stack address may differ for instances of
> > the same binary launched under different circumstances.
> > But I don't think that renders the problem impossible.
> > One could have a global pointer, resolvable at link
> > time, which could be set to SP+delta by whatever
> > we call crt0 these days, and which should provide the
> > required semantics.  Each user thread startup or 
> 
> Resolvable at link time and set by crt0 seem to be mutually
> exclusive... but perhaps I'm misunderstanding you.

You are.  The *address* of the pointer to the pointer
can be resolved at link time.  The *value* of the pointer
to the pointer is set by crt0 (if stack origins are not
intrinsically fixed at link time - if they are, the indirection
is not necessary).

> In any case, that's not the real problem.  Linux user threads do not
> have true separate stacks.  They share their _entire_ address space;
> the stacks are all bounded (default is 2MB) and grouped together at the
> top of the available memory region.

Exactly.  But if all we all we are worried about is thread
specific data for user threads multiplexed on exactly
one kernel thread, we could probably get by with a
simple global variable for the thread pointer for the
current user thread running in the process.   It's the
case of multiple user threads running within multiple
*kernel* threads (e.g. created by fork()) that complicates
things, and makes people want to use a register
or other storage resource associated with exactly one
kernel thread (and CPU).  A permanently assigned
register, as we have seen, creates various complications,
so I'm looking for another kernel-thread-specific resource,
of which I believe the stack region is the best candidate.
Each process/task/program would have a single global
variable, which points to a common address in the
stack region of each kernel thread, which is used
to store the address of the user-thread-specific
data of the user thread executing on that kernel thread.

Of course, I still haven't seen an informed description
of the actual problem that Ulrich and H.J. are trying to
solve, so it may in fact be simpler (or more complex).

            Regards,

            Kevin K.