Re: Is gcc thread-unsafe?

[Andrew Haley <aph@redhat.com>]

Bart Van Assche writes:
 > On 10/30/07, Andrew Haley <aph@redhat.com> wrote:
 > > David Schwartz writes:
 > > >
 > > > Can we get some kind of consensus that 'optimizations' that add
 > > > writes to any object that the programmer might have taken the
 > > > address of are invalid on any platform that supports memory
 > > > protection?
 > >
 > > That's what the proposed standard language says, kinda-sorta.  There's
 > > an informal description at
 > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html.
 > 
 > There is other important information in the cited text. A.o. it is
 > explained that register promotion of potentially shared variables
 > can introduce data races. Or: register promotion can introduce bugs
 > in multithreaded software when compiled with optimization
 > enabled. Are there any register promotion transformations
 > implemented in gcc that can introduce data races in multithreaded
 > software ?

I expect so.  We're going to have to audit this whole enormous code
base to find them all and take them out.

Note that some of these optimizations have been around since gcc 3.4.

 > This is very important information both for kernel developers and
 > for developers of multithreaded userspace applications.

 > Another conclusion from the cited text is that in contrast with
 > what was stated before on the gcc mailing list, it is not required
 > to declare thread-shared variables volatile if that thread-shared
 > data is consistently protected by calls to locking functions.

Well, let's be clear: ISO 9899:1999 doesn't say so, but the proposed
standard language does.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903