From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16677 invoked by alias); 1 Jun 2005 03:02:40 -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 16374 invoked by uid 22791); 1 Jun 2005 03:02:25 -0000 Received: from quokka.dot.net.au (HELO quokka.dot.net.au) (202.147.68.16) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 01 Jun 2005 03:02:25 +0000 Received: from [203.129.47.149] (helo=ppp-47-149.grapevine.net.au) by quokka.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1DdJUO-0005PK-00; Wed, 01 Jun 2005 13:01:53 +1000 Subject: Re: New pthread_once implementation From: Ross Johnson To: Gottlob Frege Cc: Vladimir Kliatchko , Pthreads-Win32 list In-Reply-To: <97ffb3105053109285d5660ad@mail.gmail.com> References: <1117446923.7427.5.camel@desk.home> <0IHB00BP81S8NK@mta5.srv.hcvlny.cv.net> <97ffb3105053109285d5660ad@mail.gmail.com> Content-Type: text/plain Date: Wed, 01 Jun 2005 03:02:00 -0000 Message-Id: <1117594912.6822.67.camel@desk.home> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005/txt/msg00105.txt.bz2 On Tue, 2005-05-31 at 12:28 -0400, Gottlob Frege wrote: > I think that might be reasonable. > > Here's another tact we could try: > > In the case of cancel, release the semaphore BUT do NOT reset the > control state. In the waiting case, after waiting, check if state == > done. If not done, we know something went wrong - fall back to using > a named mutex. Note that ALL new threads coming in will go to the > wait case then into the namedmutex code - after a cancel, no threads > try to call init in the normal way. > > Does that make sense? The cancellation handler must change 'state' before checking for the semaphore, otherwise there's no possibility of managing the race between the cancelled thread and a thread that has just entered the wait track but not yet created the semaphore. That waiter will be stranded until a new thread comes by. The form of pthread_once with the MCS queue-based lock is the same as that proposed by Alexander. Vlad's MCS lock implementation is the missing element: it is light-weight in the uncontended case; is efficient otherwise (including attempting to minimise cache-coherence operations on MP systems), and; can be incorporated without changing the library's ABI. I think it deserves inclusion in the next release. If there are refinements that can be made to pthread_once later then they can be considered, but in the meantime we will have a fully working, robust, and efficient pthread_once. Ross