From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15746 invoked by alias); 14 Mar 2005 02:47:27 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 15674 invoked from network); 14 Mar 2005 02:47:17 -0000 Received: from unknown (HELO canyonero.dot.net.au) (202.147.68.14) by sourceware.org with SMTP; 14 Mar 2005 02:47:17 -0000 Received: from [202.147.85.59] (helo=ip-85-59.dot.net.au) by canyonero.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1DAfbw-0000oM-00 for ; Mon, 14 Mar 2005 13:47:16 +1100 Subject: Re: starvation in pthread_once? From: Ross Johnson To: Pthreads-Win32 list In-Reply-To: <97ffb31050308081116245b75@mail.gmail.com> References: <97ffb31050308081116245b75@mail.gmail.com> Content-Type: text/plain Date: Mon, 14 Mar 2005 02:47:00 -0000 Message-Id: <1110768429.20103.115.camel@desk.home> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005/txt/msg00043.txt.bz2 On Tue, 2005-03-08 at 11:11 -0500, Gottlob Frege wrote: > Do you think it is worth avoiding the named_mutex in favor of a event > only created on contention (my version)? (I do, obviously). > I agree. Win32 mutexes are VERY slow, even for uncontended lock operations - that is, about 50 times slower than a CriticalSection. I would guess that a named mutex is even slower again. A CS is about the same speed as an interlocked operation if it doesn't block. I also think that generating the [guaranteed unique] name is a complication that should be avoided if possible. News: I've dropped a new version of pthread_once into CVS (bumping the library's version from 1 to 2, and dll's name to indicate an ABI change). It's based on the code that Gottlob posted earlier:- http://sources.redhat.com/ml/pthreads-win32/2005/msg00029.html This code works fine without cancellation, but with it included, the design's efficiency had to be downgraded a little. Threads waiting on a cancelled initter thread must be woken to compete again to run the init_routine. I couldn't find any way to manage the repeated creation/reuse/closure of the event properly without a global CS, but at least these sections are very short where it matters most. See:- http://sources.redhat.com/cgi-bin/cvsweb.cgi/pthreads/pthread_once.c? rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=pthreads-win32 Crucially, the event is still a per once_control object that is released on successful return from pthread_once. I plan on releasing one more pthread*1.dll snapshot to include init_routine cancellability based on the global cond+mutex used in the last snapshot, then a pthread*2.dll snapshot using the above code. (DLL names change only when their ABI compatibility is affected). Thanks. Ross > I'm guessing that for typical usage, contention will be low. And, in > my own code, I'm considering making statically initialized mutexes (or > CSes) by using a call_once in their constructor. It would just seem > like overkill if all my mutexes needed a mutex to init themselves. > > > On Tue, 8 Mar 2005 10:58:23 +0100, Alexander Terekhov > wrote: > > > > Grrr. Bad day. > > > > if (!once_control) { > > named_mutex::guard guard(&once_control2); > > if (!once_control2) { > > > > once_control2 = true; > > } > > once_control = true; > > } > > > > regards, > > alexander. > > > > Alexander Terekhov/Germany/IBM@IBMDE@sources.redhat.com on 03/08/2005 > > 10:55:53 AM > > > > Sent by: pthreads-win32-owner@sources.redhat.com > > > > To: Ross Johnson > > cc: Pthreads-Win32 list > > Subject: Re: starvation in pthread_once? > > > > > > > DCSI-TLS: (__declspec(thread) for control variable; DLL issues > > > aside for a moment) > > > > > > if (!once_control) { > > > named_mutex::guard guard(&once_control); > > > if (!once_control) { > > > > > > once_control = true; > > > } > > > } > > > > Sorry, I meant: > > > > if (!once_control) { > > named_mutex::guard guard(&once_control); > > if (!once_control2) { > > > > once_control2 = true; > > } > > once_control = true; > > } > > > > where once_control2 is a non-TLS flag. > > > > regards, > > alexander. > > > > >