From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32185 invoked by alias); 2 Jun 2005 12:59:13 -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 32154 invoked by uid 22791); 2 Jun 2005 12:59:01 -0000 Received: from mta1.srv.hcvlny.cv.net (HELO mta1.srv.hcvlny.cv.net) (167.206.4.196) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 02 Jun 2005 12:59:01 +0000 Received: from optonline.net (hamstr2.srv.hcvlny.cv.net [167.206.5.9]) by mta1.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHG00F2KK46C9@mta1.srv.hcvlny.cv.net> for pthreads-win32@sources.redhat.com; Thu, 02 Jun 2005 09:00:07 -0400 (EDT) Received: from [10.240.3.32] (Forwarded-For: [199.172.169.15]) by mstr2.srv.hcvlny.cv.net (mshttpd); Thu, 02 Jun 2005 08:58:59 -0400 Date: Thu, 02 Jun 2005 12:59:00 -0000 From: vkliatchko@optonline.net Subject: Re: RE: New pthread_once implementation To: Ross Johnson Cc: Gottlob Frege , Pthreads-Win32 list Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-SW-Source: 2005/txt/msg00106.txt.bz2 > -----Original Message----- > From: Ross Johnson [mailto:ross.johnson@homemail.com.au] > Sent: Thursday, June 02, 2005 2:20 AM > To: Vladimir Kliatchko > Subject: RE: New pthread_once implementation > > On Thu, 2005-06-02 at 15:57 +1000, Ross Johnson wrote: > > Vlad, > > > > In ptw32_mcs_flag_set, can I add a check to avoid calling SetEvent(-1)? > > I.e.: > > > > if (0 != e && -1 != e) > > { > > ... > > > > Ross > > > > Although, it looks like there can only be one call to ptw32_mcs_flag_set > for any one flag. But is it always the case? MCS locks guarantee that the there is one and only one thread setting the flag (for the 'ready' flag: the thread that owns the lock; for the 'next' flag: the next thread in the queue) and there is one and only one thread waiting on the flag (for the 'ready' flag: the next thread in the queue; for the 'next' flag: the previous thread in the queue). Because of this property we do not need to check the flag for -1. Note also that if MCS locks allowed multiple threads to wait for or signal the same event, we would not be able to close the event handle without a race condition. Basically we would be back facing exactly the same problem we had with the reference counting versions. > > Also, in pthread_once - don't we still need some acquire/release fences > when reading/setting 'done'? MCS locks were meant to work similar to mutexes. I.e., once a critical section is protected by a lock one does not need memory fences inside the section because the 'acquire' and 'release' routines take care of these. All of the interlocked routines plus SetEvent and WaitForSingleObject inside the 'acquire' and 'release' routines have semantics of full memory barriers. What have we decided regarding the license? Regards, --vlad > > if (!once_control->done) // <<< Here > { > pthread_cleanup_push(ptw32_once_on_init_cancel, (void *)&node); > (*init_routine)(); > pthread_cleanup_pop(0); > > once_control->done = PTW32_TRUE; // <<< and here? > } > > ptw32_mcs_lock_release(&node); > } > > Ross >