[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2e108260711020829p5994f79bp48ca35a1ce84ff03@mail.gmail.com>
Date: Fri, 2 Nov 2007 16:29:13 +0100
From: "Bart Van Assche" <bart.vanassche@...il.com>
To: "Andrew Haley" <aph@...hat.com>
Cc: "David Schwartz" <davids@...master.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Tomash Brechko" <tomash.brechko@...il.com>
Subject: Re: Is gcc thread-unsafe?
On 10/30/07, Andrew Haley <aph@...hat.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 ? 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.
Bart Van Assche.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists