From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17433 invoked by alias); 11 Jul 2012 08:44:39 -0000 Received: (qmail 17413 invoked by uid 22791); 11 Jul 2012 08:44:38 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Jul 2012 08:44:20 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6B8iEpe026548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2012 04:44:14 -0400 Received: from zebedee.pink (ovpn-113-34.phx2.redhat.com [10.3.113.34]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6B8i9TW017280; Wed, 11 Jul 2012 04:44:11 -0400 Message-ID: <4FFD3CD9.4030206@redhat.com> Date: Wed, 11 Jul 2012 08:44:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: David Miller CC: roland@hack.frob.com, maxim@codesourcery.com, joseph@codesourcery.com, rdsandiford@googlemail.com, libc-ports@sourceware.org, libc-alpha@sourceware.org Subject: Re: [PATCH] Unify pthread_spin_[try]lock implementations. References: <65B470D2-4D01-4BA1-AEC5-A72C0006EA22@codesourcery.com> <20120711081441.73BB22C093@topped-with-meat.com> <20120711.012509.1325789838255235021.davem@davemloft.net> In-Reply-To: <20120711.012509.1325789838255235021.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2012-07/txt/msg00024.txt.bz2 On 07/11/2012 09:25 AM, David Miller wrote: > From: Roland McGrath > Date: Wed, 11 Jul 2012 01:14:41 -0700 (PDT) > >>> +int >>> +pthread_spin_lock (pthread_spinlock_t *lock) >>> +{ >>> + while (atomic_compare_and_exchange_val_acq (lock, 1, 0) != 0) >>> + while (*lock != 0) >>> + ; >> >> What's the inner loop for? > > I guess the idea is to spin with non-atomic reads when the lock is > contended so we don't do expensive bus cycles grabbing the cache line > in exclusive state over and over again. > > If we spun using only the atomic it would be very expensive. Sure, but on ARM at least there's no guarantee that the local processor will see changes to the state of the lock when another processor frees it. Andrew.