Re: Q: Thread local storage, thread IDs

Khimenko Victor (khim@sch57.msk.ru)
Wed, 28 Jul 1999 00:24:23 +0400 (MSD)


In <379DEFFC.5208531A@trantor.de> JŸrg Pleumann (joerg.pleumann@trantor.de) wrote:
> Hello Chris,

> cd_smith@ou.edu wrote:

>> > (2) 1-based IDs for the threads belonging to a process (in addition to
>> > the system-wide unique process IDs).
>>
>> What do you mean by 1-based? Do you mean that you want to require that
>> the first thread in a process always has TID 1? That's pretty kuldgy, and
>> very non-portable if you actually use it. If you need 1-based ID's, use
>> TLS and a mutex-protected global variable and have threads allocate their
>> process-local ID at startup and then increment the counter.

> I need 1-based thread IDs because the thread local storage mechanism
> implemented in the Pascal compiler run-time library expects 1-based IDs
> for a simple lookup of a thread variable's value in a table. Kind of

> address(variable) + (tid - 1) * total_tls_size.

> It all works only for global variables, so total_tls_size is a fixed
> value for the program. I guess it's exactly what Delphi does. I could
> change this, of course, but I don't want to make more changes to the
> original RTL than absolutely necessary.

Adding such stuff to kernel looks MUCH worse to me then fixing RTL. I hope
you'll be unable to pass it over Linus anyway :-)

>> I doubt that the kernel really does any screwing around with the values of
>> registers for the context. If so, I've lost a lot of what respect I
>> previously had for any of these operating systems. More likely, the use
>> of FS for that purpose is a convention used by the program, and the kernel
>> properly context switches, without caring what you're using your registers
>> for.

> In OS/2 and Windows, the FS selector *initially* points to a thread
> information block for the current thread. Of course you can change the
> value of FS, and this value will still be valid after a context switch.
> So the use of FS the way I described it is really a convention used by
> the program (and recommended by the OS). But I don't see how I can
> implement this convention in my program if the Linux kernel forces me to
> use

> ds=es=fs=gs

> and doesn't allow me to create a new selector/offset pair for a given
> address. On the other hand I'm not such an i386 protected mode assembler
> geek, so it is possible that I've missed some command while browsing
> through my assembler books.

Linux uses FLAT address space. And FLAT means exactly this: flat. No selectors.
In userspace that is. No way to create new selector and no need to change
[csdefg]s at all. You'll need really, really, REALLY strong argument to change
this. And even then such patch will be rejected :-)) No way, sorry. Linux 2.2
uses 1 selector per process (for TSS) and 2.3 does not use even one selector
per process and it's worth it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/