From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10465 invoked by alias); 24 Feb 2005 22:22:14 -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 10336 invoked by uid 48); 24 Feb 2005 22:22:06 -0000 Date: Fri, 25 Feb 2005 03:30:00 -0000 Message-ID: <20050224222206.10335.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/msg03063.txt.bz2 List-Id: ------- Additional Comments From davids at webmaster dot com 2005-02-24 22:22 ------- > They are non-portable no matter how static initializers are done: > C++ doesn't include threads and POSIX doesn't include C++. That's a bogus argument. There are no conflicts between the two standards. > Taking portability aside (as they are already non-portable), this is > a wonderful quote when taken out of context. Yeah, if an option makes > more code working and its negation makes more code break, let's make > the breaking variant the default :-) In any context, I stand by this quote. Code that does not conform to the standards it requests during compilation should break. Compatability options that make code work are fine, they just should not be on by default, especially when they have a performance cost. Broken code should break. > For me static locals in C++ are the equivalent of pthread_once in C/POSIX. > A hypothetical C++/POSIX should make them MT-safe. They are MT-safe, provided you lock shared data that may be accessed concurrently. POSIX never permits you to modify shared data in one thread when it may be accessed by another without a lock. By your definition of MT-safe, almost no function is MT-safe. Is 'strchr' MT-safe if you call it on a string while another function might modify that string? No, so lets put automatic locks around 'strchr' and any function that might modify a string. A function is MT-safe if it does the same thing in an MT context that it does in a UT context, provided the caller uses locks to prevent access to data in one thread while another thread might access it. Static initialization is already MT safe and these locks do not make it more so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099