From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4750 invoked by alias); 22 May 2009 21:03:20 -0000 Received: (qmail 30897 invoked by uid 48); 22 May 2009 21:03:06 -0000 Date: Fri, 22 May 2009 21:03:00 -0000 Message-ID: <20090522210306.30894.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/40088] Creating a std::ostringstream object locks a global mutex In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "veloso at verylowsodium dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg01887.txt.bz2 ------- Comment #9 from veloso at verylowsodium dot com 2009-05-22 21:03 ------- (In reply to comment #4) > Hm. I wonder how the "global" locale is supposed to interact with multiple > threads anyway (in the face of C++ not knowing about threads). Would it be > a conforming implementation to put the global locale into thread-local storage > (thus, having a "global" locale for each thread)? Pre C++0x, the standard says nothing about threads at all. The C++0x draft has this to say: Whether there is one global locale object for the entire program or one global locale object per thread is implementation defined. Implementations are encouraged but not required to provide one global locale object per thread. If there is a single global locale object for the entire program, implementations are not required to avoid data races on it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088