From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17876 invoked by alias); 22 Feb 2005 10:28:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17359 invoked by uid 48); 22 Feb 2005 10:27:34 -0000 Date: Tue, 22 Feb 2005 15:59:00 -0000 Message-ID: <20050222102734.17358.qmail@sourceware.org> From: "gniccolai at yahoo dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050220004607.20099.davids@webmaster.com> References: <20050220004607.20099.davids@webmaster.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/20099] -pthreads should imply -fno-threadsafe-statics X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg02623.txt.bz2 List-Id: ------- Additional Comments From gniccolai at yahoo dot com 2005-02-22 10:27 ------- > > You say a hypothetical multithreaded C++ should state this as the semantics for > static locals, and I don't disagree with you, provided we are not talking about > one based on POSIX threads. POSIX specifically made the design decision to > always require explicit locks and to always require the programmer to find, > document, and lock cases where concurrent accesses might occur. I think I wrote a rationale that explains and justifies this choice at http://www.niccolai.ws/works/articoli/art-multithreading-en-1a.html I had not been able to find an official rationale from open group; the nearest thing seems to be: http://www.unix.org/whitepapers/reentrant.html If more precise and authoritative ones are available, please point them out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099