[Top] [All Lists]

Re: thread-ready ABIs

To: "Kevin D. Kissell" <>
Subject: Re: thread-ready ABIs
From: Dominic Sweetman <>
Date: Tue, 22 Jan 2002 09:59:53 +0000
Cc: "Ralf Baechle" <>, "Ulrich Drepper" <>, "Mike Uhler" <>, <>, "GNU libc hacker" <>, "H . J . Lu" <>
In-reply-to: <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses>
References: <m3elkoa5dw.fsf@myware.mynet> <> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <> <m3d703thl6.fsf@myware.mynet> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses>
User-agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (中ノ庄) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux)

Since nobody seems to be prepared to essay a brief definition of a
thread register, I'll make one up from first principles and maybe the
experts will beat it into shape.

Multiple threads in a Linux process share the same address space: code
and data.  A thread has its own unique stack, but since (by
definition) it shares all its data with every other thread it has no
identity - there is no thread-unique static data.  That means it has
no handle to acquire and manage any thread-specific variables.

[Some threads purists would probably maintain that's a Good Thing:
 threads to them are like electrons to quantum physicists,
 indistinguishable by definition].

Linux is not noted for computer science purity; so an OS-maintained
"thread identity" variable which is cheap to read in user space sounds
a useful thing to have.

A patient Linux expert (if any such are reading this list) might like
to say what value is typically held (a pointer? an index?) and how
it's used (my money's on "wrapped in an impenetrable macro").

In a more baroque (synonym for "less backward"?) architecture there
are usually registers hanging about which no compiler or OS author has
previously figured out any use for, which can be bent to this purpose.
Unfortunately, MIPS original architects committed the grave error of
making all the registers useful.

I quite like the idea of putting the thread value at a known offset in
low virtual memory, but I expect the kernel keeps virtual page 0
invalid to catch null pointers and that instructions start at the
first boundary which doesn't create cache alias problems...

Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032

<Prev in Thread] Current Thread [Next in Thread>