Subj : Re: Adding thread support for C... To : comp.programming.threads From : David Hopwood Date : Sat Jul 23 2005 01:45 am Mayan Moudgill wrote: > The compiler was eliminating the wait-loops [as it should]. We had to > introduce a mechanism to inhibit this optimization. > > It turns out that, as the compiler starts optimizing more, and worse, > doing whole program optimizations, it becomes critical with > multi-threaded programs to make sure that the compiler can distinguish > between optimizations that would be correct in single-threaded C but are > invalid in multi-threaded codes. The code that you are trying to write implements concurrency primitives, which you should not expect to have a portable implementation in C. It makes little sense to try to implement these things in C, since C neither has a well-defined concurrent semantics of its own, nor does it expose the semantics of the underlying machine in a usable way. That's why you can only work around various problems by inhibiting optimizations: it is impossible to write correct code in C that meets the requirements, only code that happens to work for particular implementations of C. Writing in assembler has better-defined semantics than C for this case -- at least for most processor architectures, there is a documented memory model at the assembler (i.e. ISA) level. In languages that were designed from the start to have a concurrent semantics, you don't hear people complaining that application code can be broken by optimizations. Why not? Because the code that can potentially be broken by optimization is in that case not application code; it's code that is part of (or generated by) the language implementation. IOW, issues like this are the language implementors' problems, which is just how it should be. -- David Hopwood .