mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: davids@webmaster.com, "Torvalds,
	Linus" <torvalds@linux-foundation.org>,
	"Kleen, Andi" <ak@suse.de>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: Is gcc thread-unsafe?
Date: Fri, 26 Oct 2007 12:59:10 +0100	[thread overview]
Message-ID: <18209.54926.290448.957962@zebedee.pink> (raw)
In-Reply-To: <200710260922.54428.nickpiggin@yahoo.com.au>

Nick Piggin writes:
 > Can you retain cc list, please?
 > 
 > On Friday 26 October 2007 07:42, David Schwartz wrote:

 > > 	I asked a collection of knowledgeable people I know about the
 > > issue. The consensus is that the optimization is not permitted in
 > > POSIX code but that it is permitted in pure C code. The basic
 > > argument goes like this:
 > >
 > > 	To make POSIX-compliant code even possible, surely
 > > optimizations that add writes to variables must be
 > > prohibited. That is -- if POSIX prohibits writing to a variable
 > > in certain cases only the programmer can detect, then a
 > > POSIX-compliant compiler cannot write to a variable except where
 > > explicitly told to do so. Any optimization that *adds* a write to
 > > a variable that would not otherwise occur *must* be prohibited.

I don't think that POSIX is quite as explicit as that.  See
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

 > > 	Otherwise, it is literally impossible to comply with the POSIX
 > > requirement that concurrent modifications and reads to shared
 > > variables take place while holding a mutex.
 > 
 > Now all you have to do is tell this to the gcc developers ;)

We're listening, really.  It's unacceptable that gcc should break
code.

However, fixing it is hard.  The best plan is probably to implement
(part of) the proposed standard memory model, and that requires
careful consideration.  We could in theory simply disable this
particular optimization, but that probably isn't a good idea on its
own because other optimizations might well break other code in a
similar way.  We need to have a very close look at the thread-safe
memory model in order to determine where we do things that might
break.

An official standard containing this is still at least two years out.

Andrew.

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

  parent reply	other threads:[~2007-10-26 12:58 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-25  3:24 Nick Piggin
2007-10-25  3:46 ` Arjan van de Ven
2007-10-25  3:58   ` Nick Piggin
2007-10-25  4:29     ` David Schwartz
2007-10-25  4:35       ` Arjan van de Ven
2007-10-25 18:45         ` Måns Rullgård
2007-10-25  4:47       ` Nick Piggin
2007-10-25  9:40         ` Samuel Tardieu
2007-10-25  9:44         ` Samuel Tardieu
2007-10-25  9:54           ` Samuel Tardieu
2007-10-25  9:55           ` Andi Kleen
2007-10-25  7:15 ` Andi Kleen
2007-10-25 11:58   ` linux-os (Dick Johnson)
2007-10-25 12:16     ` Andi Kleen
2007-10-25 22:49   ` Nick Piggin
2007-10-25 23:09     ` Andi Kleen
2007-10-25 23:14       ` Linus Torvalds
2007-10-25 23:16         ` Andi Kleen
2007-10-25 23:32           ` Linus Torvalds
2007-10-25 23:42             ` Andi Kleen
2007-10-25 23:57               ` Linus Torvalds
2007-10-26  1:15                 ` Zachary Amsden
2007-10-26  4:57               ` Willy Tarreau
2007-10-25 23:43       ` Nick Piggin
2007-10-25 23:55         ` Andi Kleen
2007-10-25 23:57           ` Nick Piggin
2007-10-25 14:55 ` Linus Torvalds
2007-10-25 15:12   ` Pekka Enberg
2007-10-25 21:42   ` David Schwartz
2007-10-25 23:22     ` Nick Piggin
2007-10-26 11:59       ` Andrew Haley
2007-10-26 11:59       ` Andrew Haley [this message]
2007-10-26 17:39         ` Chris Friesen
2007-10-25 22:26   ` Ismail Dönmez
2007-10-25 22:56     ` Jeff Garzik
2007-10-25 23:04       ` Jeff Garzik
2007-10-31 22:10 ` Phillip Susi
     [not found] <fa.JbRGo0cQWncrcfKHmiNdvchsA50@ifi.uio.no>
     [not found] ` <fa.8qDECVaPIo7DWbjhQbyw6N5Infg@ifi.uio.no>
     [not found]   ` <fa.M4DOMggyrQmdTqekWSuw4xCxiTc@ifi.uio.no>
2007-10-25 23:27     ` Robert Hancock
     [not found] <e2e108260710260729x4603211cgb68d7434ce1e54e9@mail.gmail.com>
2007-10-26 14:40 ` Bart Van Assche
2007-10-26 15:09   ` Linus Torvalds
2007-10-26 15:34     ` Andrew Haley
2007-10-26 18:06       ` David Schwartz
2007-10-30 10:20         ` Andrew Haley
2007-11-02 15:29           ` Bart Van Assche
2007-11-02 15:38             ` Andrew Haley
2007-11-04 15:13               ` Bart Van Assche
2007-11-04 17:45                 ` Linus Torvalds
2007-11-04 17:58                   ` Andrew Haley
2007-11-04 18:06                   ` Bart Van Assche
2007-11-02 17:18             ` David Schwartz
2007-10-26 21:45     ` Giacomo Catenazzi
2007-10-26 22:24       ` Linus Torvalds
2007-10-26 15:27   ` Linus Torvalds
2007-10-26 16:28     ` Linus Torvalds
2007-10-26 17:07       ` Bart Van Assche
2007-10-26 17:12         ` Andrew Haley
2007-10-26 17:25           ` Linus Torvalds
2007-10-26 18:08         ` Alan Cox
2007-10-26 18:14           ` Linus Torvalds
2007-10-26 20:39           ` Andi Kleen
2007-10-28 18:19 linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18209.54926.290448.957962@zebedee.pink \
    --to=aph@redhat.com \
    --cc=ak@suse.de \
    --cc=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®