Subj : Re: Stack in thread-local virtual memory?
To   : comp.programming.threads
From : David Hopwood
Date : Mon Aug 22 2005 11:58 pm

Ulrich Eckhardt wrote:
> 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);

Can 'join' fail?

>    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.

This looks like the kind of code that could be mis-optimized by a compiler
that is not sufficiently aware of threading. In a single-threaded program,
depending on the code of 'join', it could be correct to treat a_foo as dead
after the create_thread call.

Still, I'm quite surprised if that is happening, since even in single-threaded
C, create_thread could potentially copy &a_foo into a global variable, and so
the compiler would have to know that 'join' does not access any such variable
in order to treat a_foo as dead.

> 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.

It's likely to be architecture-dependent whether there is any advantage in
optimizing based on a_foo being dead. (Or even if the generated code is
incorrect, you might not see it.)

I gather that since you no longer have access to the machine where it failed,
you can't disassemble main() to see whether it looks correct?

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

.