From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8118 invoked by alias); 15 Jun 2012 02:50:02 -0000 Received: (qmail 8057 invoked by uid 22791); 15 Jun 2012 02:50:00 -0000 X-SWARE-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Jun 2012 02:49:47 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SfMbb-0002V6-1m from Maxim_Kuvyrkov@mentor.com ; Thu, 14 Jun 2012 19:49:47 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jun 2012 19:49:10 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Fri, 15 Jun 2012 03:49:45 +0100 Subject: Re: [PATCH] Optimize libc_lock_lock for MIPS XLP. MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="iso-8859-1" From: Maxim Kuvyrkov In-Reply-To: <4FDAA190.3050706@tilera.com> Date: Fri, 15 Jun 2012 02:50:00 -0000 CC: "Joseph S. Myers" , GLIBC Devel , , Tom de Vries Content-Transfer-Encoding: quoted-printable Message-ID: References: <4FD9DB74.8080905@tilera.com> <40CBC472-71CC-4FF3-A452-073B76701215@codesourcery.com> <4FDAA190.3050706@tilera.com> To: Chris Metcalf 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-06/txt/msg00043.txt.bz2 On 15/06/2012, at 2:44 PM, Chris Metcalf wrote: > On 6/14/2012 9:20 PM, Maxim Kuvyrkov wrote: ... >> As I read it, in case of a contended lock __lll_lock_wait will reset the= value of the lock to "2" before calling lll_futex_wait(). I agree that th= ere is a timing window in which the other threads will see a value of the l= ock greater than "2", but the value will not get as high as hundreds or bil= lions as it will be constantly reset to "2" in atomic_exchange in lll_lock_= wait(). >>=20 >> I do not see how threads will get into a busywait state, though. Would = you please elaborate on that? >=20 > You are correct. I was thinking the that the while loop had a cmpxchg, b= ut > since it's just a straight-up exchange, the flow will be something like: >=20 > - Fail to initially call lll_futex_wait() if the lock is contended > - Fall through to while loop > - Spin as long as the lock is contended enough that *futex > 2 > - Enter futex_wait >=20 > So a little busy under high contention, but probably settles out reasonab= ly > well. Exactly. I will include the above scenario in the comment to make it more = transparent. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics