Subj : Stack in thread-local virtual memory?
To   : comp.programming.threads
From : Ulrich Eckhardt
Date : Tue Aug 23 2005 12:04 am

Greetings!

In advance, let me tell you that I don't rule out a mistake on my side, but
usually I'm not that stupid and I did my share of multithreaded
programming.
Now, what I had was this:

void thread_entry( void* p)
{
   foo* f = p;
   do_this(f);
}

int main()
{
   foo a_foo;
   thread t = create_thread( &thread_entry, &a_foo);
   join(t);

   return 0;
}

Simple thing, fork off a worker thread and wait until it has finished - to
be precise I only waited until it had initialised and passed an pointer to
a win32 event handle, but for sure I did not return from main() so the
reference to a_foo was valid all the time.

Now, what I experienced was that the thread failed with an access violation
when it tried to access the foo via the passed pointer. When I moved the
object from the main function to the global scope, it worked. And no, I
did not access it as global but still only via the pointer passed to
thread_entry().

Now, for the details: the system was a normal PC, running CEPC, i.e. MS
Windows CE 4.2 for PCs. Unfortunately, I don't have access to that system
anymore (it was at a training), but I tried the same on a different CE
based system (Alchemy Au1100, a MIPS32 machine) and I couldn't reproduce
the error there.

Pondering about this, I came to the conclusion that CE already made heavy
use of virtual memory tricks which limit the running applications but make
some memory management related issues easier to handle, so why not do the
same with the stack? If each thread had its stack at the same address in
virtual memory, you'd sacrifice the ability to share objects on the stack
with other threads (which you rarely do anyway) but gain an additional
register in your CPU (if I understand typical implementations correctly).

My question now is whether anyone ever heard of anything like this or if I
have just been hallucinating?

Uli

.