Simon Thum <[EMAIL PROTECTED]> 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 _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
