xquartz dereferencing a NULL pointer (patch 2)

[Eirik Byrkjeflot Anonsen]

Simon Thum <simon.thum at gmx.de> writes:

>> newtail = (oldtail + 1) % QUEUE_SIZE; 
>> miEventQueue.tail = newtail;
>> 
>> becoming
>> 
>> miEventQueue.tail++;
>> miEventQueue.tail |= QUEUE_SIZE - 1;
> I don't think a compiler should be doing this to a non-local store. It
> could probably be considered a bug. C doesn't really have a memory model
> but few rules likely to forbid this. I didn't check, but I'd be highly
> surprised by this being legal. Do you have a case where it happens?

On the contrary, a c compiler is allowed to assume that the code is
running single-threaded.  Since the two code snippets above will yield
the exact same result (under the obvious assumptions), it is a valid
transformation for the compiler.

Posix only guarantees correct behaviour if you use a mutex, I believe.
There are other constructs that are likely to behave as partial memory
barriers, but they aren't guaranteed to work.  And note that as soon
as you have more than one physical core, you may need to force cache
coherence as well.

Of course, there is quite a bit of code written by now that really
depends on a non-optimizing compiler for its correctness in the face
of multiple threads.  And it is reasonable to expect that many
compilers try to avoid breaking this kind of code.  But there are no
guarantees.

For some discussion on these problems (and some horrible examples),
see "Threads cannot be implemented as a library":
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

eirik