Re: thread static (Erik Corry)
Tue, 22 Aug 1995 14:02:06 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: thread static (1995-08-18)
Re: thread static (Stefan Monnier) (1995-08-21)
Re: thread static (1995-08-21)
Re: thread static (Roger Barnett) (1995-08-21)
Re: thread static (1995-08-21)
Re: thread static (1995-08-22)
Re: thread static (1995-08-22)
Re: thread static (1995-08-24)
Re: thread static (Michael Meissner) (1995-08-24)
Re: thread static (Stefan Monnier) (1995-08-28)
Re: thread static (1995-08-28)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Erik Corry)
Keywords: parallel
Organization: Home (Freiburg)
References: 95-08-078 95-08-143
Date: Tue, 22 Aug 1995 14:02:06 GMT

: Michael McNamara <,> wrote:
: ] I recognize that one can dedicate a register to hold one's
: ] thread number, thus avoid the os call; but then consider the cost of
: ] removing a register from register allocator's pool.

Stefan Monnier ( wrote:
: Registers are not *that* scarce !

They are on most of the computers currently out there (x86).

: And don't forget a few details with your scheme:
: [..]
: - thread creation/destruction and context-switches have to go through the
: kernel: this imposes a minimum weight to your threads. But that's OK since
: most treads packages need to go into the kernel in order to setup the
: extensible stack.

But they could perhaps cache the stacks. When you destroy a thread, you
keep the extensible stack, and you can use it for future threads without
having to go to the kernel to get a new one. So it's quite possible to
make a lightweight thread without going to the kernel.

I suppose it would even be possible to make a new thread with thread
static variables without an OS call. The runtime system could allocate
the space needed, and the static variables could be accessed through
some sort of table of pointers. This would mean that the variables had a
differrent address in each thread. Sounds like a lot of work for the
compiler writer/runtime library writer though.

To the good objections to thread static variables that you mentioned
I'd like to add that there are serious problems with static variables
in the first place.

1) It is difficult to see where they are used and changed, because they
      are available in all functions. This leads to bugs when the program
      is updated.

2) Excessive use of static variables leads to inflexible programs
      where you cannot have more than one instance of a window or other

3) Static variables can easily be used for hidden communication between
      various bits of the program that make it impossible to separate the
      program into reusable tools.

So I think it's OK to make it slightly more difficult to use static
variables. You should have to think before making a static variable.

Erik Corry


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.