Miriam Ruiz
random thoughts on technology and life

{November 08, 2007}   C and multithreading

Reading mig21′s weblog, in which I often find really interesting stuff, I found Ian Lance Taylor’s article “Single Threaded Memory Model“, which kind of bothers me a bit. It reports a recent discussion on the gcc and LKML mailing lists about how C compilers, gcc in this case, optimize for single threaded code, sometimes leading to counter-intuitive results which won’t work properly in multi-threaded software (leading, for example, to race conditions).

The interesting part is that the C language standard, which in general describes a single threaded model, apparently says nothing about when values have to be written to memory. Thus, this kind of optimization seem to be perfectly valid. Linus Torvalds complains about gcc developers taking more care about “what the spec says” than about real problems, but the fact is that if those kind of optimizations are valid according to the specs, there’s no guarantee at all that it won’t happen with whatever C compiler you might be using.

To prevent this kind of behaviour in standard C, according to Ian, the variable needs to be marked as volatile, or it needs to use an explicit memory barrier. The moral in this case is that multithreading might not be as easy as it seems and should be handled with caution.

jldugger says:

This is why Java is respected as a capable multithreading system — the Java Memory model describes when and how things happen. Memory barriers are a trick that rely on the compiler not optimizing between C files as they’re defined as the top-most compilation unit. In Java that doesn’t hold true, but there are synchronization tools explicit in the language.

The position you’ve taken is basically what Torvalds is complaining about: there is no good memory model for multithreaded C. The volatile keyword doesn’t necessarily get the results you wanted. The best way to make the kernel work is to deviate from the C99 spec in favor of multithreaded application considerations. This of course means dropping some optimizations that are valid in the vast majority of single thread apps. There are bound to be more problems like this in C99, so perhaps its time to invent a smarter systems language that has some ideas to solve real world problems, instead of insisting that the gcc community solve your problems at the expense of others.

I wonder what D and nesC have thought up.

Ben Hutchings says:

Anyone who tells you multithreaded programming is easy, doesn’t understand it…or possibly using some quite different language from C, such as Erlang. If you’re interested in multithreading issues, Herb Sutter’s Effective Concurrency series and Tim Bray’s Wide Finder saga may be worth following. Also see the C++ memory model, which has been incorporated into the next C++ standard and has been designed to be suitable for C as well.

mig21 says:

jldugger: You are right, there is something called Java Memory model (as well as the C memory spec, obsolete for multithreading but with work in progress as Ben says) But Java Model allows the occurrence of counter-intuitive behavior and subtle differences between architectures (see Where the metal meets JVM (An interview with Cliff Click)) No one can scape from reading the spec, multithreading is hard :/

(Thank you, Miriam ;) )

jldugger says:

The problem with Java is mostly that programmers are deathly afraid of the synchronized keyword, when it solves exactly their problem. Also, if your program is big enough that you can’t be sure whether it’s threadsafe, make sure your testing looks like production. Sort of a duh, but I guess people test on Windows when the clients use Niagra / Solaris.

Leave a Reply


This is a personal webpage that belongs to Miriam Ruiz.
If you want to contact her, you can do at:

July 2017
« Nov    

La Lista de Sinde