From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20024 invoked by alias); 26 Aug 2013 16:45:19 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 19976 invoked by uid 89); 26 Aug 2013 16:45:19 -0000 Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Aug 2013 16:45:19 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_05,NO_RELAYS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: brightrain.aerifal.cx Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1VDzud-00077j-00; Mon, 26 Aug 2013 16:45:07 +0000 Date: Mon, 26 Aug 2013 16:45:00 -0000 To: =?utf-8?B?T25kxZllaiBCw61sa2E=?= Cc: Carlos O'Donell , Torvald Riegel , GLIBC Devel , libc-ports Subject: Re: [PATCH] Unify pthread_once (bug 15215) Message-ID: <20130826164507.GA20515@brightrain.aerifal.cx> References: <1368024237.7774.794.camel@triegel.csb> <519D97E4.4030808@redhat.com> <20130826124955.GA6065@domone.kolej.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130826124955.GA6065@domone.kolej.mff.cuni.cz> User-Agent: Mutt/1.5.21 (2010-09-15) From: Rich Felker X-SW-Source: 2013-08/txt/msg00046.txt.bz2 On Mon, Aug 26, 2013 at 02:49:55PM +0200, Ondřej Bílka wrote: > On Thu, May 23, 2013 at 12:15:32AM -0400, Carlos O'Donell wrote: > > On 05/08/2013 10:43 AM, Torvald Riegel wrote: > > > Note that this will make a call to pthread_once that doesn't need to > > > actually run the init routine slightly slower due to the additional > > > acquire barrier. If you're really concerned about this overhead, speak > > > up. There are ways to avoid it, but it comes with additional complexity > > > and bookkeeping. > > > > We want correctness. This is a place where correctness is infinitely > > more important than speed. We should be correct first and then we > > should argue about how to make it fast. > > > As pthread_once calls tend to be called once per thread performance is > not an issue. No, pthread_once _calls_ tend to be once per access to an interface that requires static data to have been initialized, so possibly very often. On the other hand, pthread_once only invokes the init function once per program instance. I don't see anything that would typically happen once per thread, although I suppose you could optimize out calls to pthread_once with tls: static __thread int once_done = 0; static pthread_once_t once; if (!once_done) { pthread_once(&once, init); once_done = 1; } This requires work at the application level, though, and whether it's a net advantage depends a lot on whether multiple threads are likely to be hammering pthread_once on the same once object, and whether the arch has expensive acquire barriers and inexpensive TLS access. Rich