From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14910 invoked by alias); 31 May 2005 16:28:20 -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 14799 invoked by uid 22791); 31 May 2005 16:28:15 -0000 Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.205) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 31 May 2005 16:28:15 +0000 Received: by wproxy.gmail.com with SMTP id 50so1935382wri for ; Tue, 31 May 2005 09:28:14 -0700 (PDT) Received: by 10.54.141.10 with SMTP id o10mr3102440wrd; Tue, 31 May 2005 09:28:14 -0700 (PDT) Received: by 10.54.7.59 with HTTP; Tue, 31 May 2005 09:28:14 -0700 (PDT) Message-ID: <97ffb3105053109285d5660ad@mail.gmail.com> Date: Tue, 31 May 2005 16:28:00 -0000 From: Gottlob Frege Reply-To: Gottlob Frege To: Vladimir Kliatchko Subject: Re: New pthread_once implementation Cc: pthreads-win32@sources.redhat.com In-Reply-To: <0IHB00BP81S8NK@mta5.srv.hcvlny.cv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1117446923.7427.5.camel@desk.home> <0IHB00BP81S8NK@mta5.srv.hcvlny.cv.net> X-SW-Source: 2005/txt/msg00104.txt.bz2 On 5/30/05, Vladimir Kliatchko wrote: >=20 > Regaring MCS version: > It can be quite expensing, but only when multiple threads call pthread_on= ce > simultaneously. Also, the overhead is proportional to the number of threa= ds > so that: > 1 thread - no overhead > 2 simultaneous threads - the same overhead as in semaphore based version > 3 or more simultaneous threads - higher overhead - but is this an importa= nt > case? >=20 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 =3D=3D 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?