From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22261 invoked by alias); 26 Oct 2007 15:15:22 -0000 Received: (qmail 22249 invoked by uid 22791); 26 Oct 2007 15:15:21 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Oct 2007 15:15:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D6C792AB9B0; Fri, 26 Oct 2007 11:15:16 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8ZmwxbdQyqil; Fri, 26 Oct 2007 11:15:16 -0400 (EDT) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id AE6622AB9A0; Fri, 26 Oct 2007 11:15:16 -0400 (EDT) Message-ID: <47220475.4000703@adacore.com> Date: Fri, 26 Oct 2007 15:18:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Haley CC: Bart Van Assche , gcc@gcc.gnu.org, Andrew Pinski , Tomash Brechko Subject: Re: Optimization of conditional access to globals: thread-unsafe? References: <18210.795.425145.46885@zebedee.pink> In-Reply-To: <18210.795.425145.46885@zebedee.pink> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00477.txt.bz2 Andrew Haley wrote: > Hmmm. This is an interesting idea, but it sounds to me as though it's > somewhat at variance with what is proposed by the C++ threads working > group. In any case, gcc will certainly implement whatever the > standards committees come up with, but that is probably two years > away. One problem at the language standards level is that you can't easily talk about loads and stores, since you are defining an as-if semantic model, and if you make a statement about loads and stores, any other sequence which behaves as if that sequence were obeyed is allowed. In the absence of a notion of threads at the semantic level it's difficult to say what you mean in a formal way. In the Ada standard, we get around this problem by having sections called "implementation advice", which in practice are treated as requirements, but we can use language that is not formally sound, even though everyone knows what we mean. Of course in Ada there is a clear notion of threads semantic, and a clear definition of what the meaning of code is in the presence of threads, so the specific situation discussed here is easy to deal with (though Ada takes the view that unsychronized shared access to non-atomic or non-volatile data from separate threads has undefined effects).