From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 340 invoked by alias); 20 Feb 2005 23:59:55 -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 32764 invoked by uid 48); 20 Feb 2005 23:59:50 -0000 Date: Mon, 21 Feb 2005 16:34:00 -0000 Message-ID: <20050220235950.32763.qmail@sourceware.org> From: "davids at webmaster 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/msg02451.txt.bz2 List-Id: ------- Additional Comments From davids at webmaster dot com 2005-02-20 23:59 ------- What you keep ignoring is that the POSIX standard explicitly declares it a bug to access data in one thread while it may be modified in another. It's not "unfortunate timing", it's failure to use the proper code to ensure correct timing. 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099