From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31513 invoked by alias); 9 Feb 2013 14:56:17 -0000 Received: (qmail 31502 invoked by uid 22791); 9 Feb 2013 14:56:16 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Sat, 09 Feb 2013 14:56:06 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r19EtkTK032098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Feb 2013 09:55:46 -0500 Received: from [10.3.113.31] (ovpn-113-31.phx2.redhat.com [10.3.113.31]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r19EthEW017604; Sat, 9 Feb 2013 09:55:44 -0500 Message-ID: <5116636F.1040003@redhat.com> Date: Sat, 09 Feb 2013 14:56:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Miller CC: carlos@systemhalted.org, drow@false.org, joseph@codesourcery.com, schwab@linux-m68k.org, thomas_schwinge@mentor.com, kkojima@rr.iij4u.or.jp, marcus.shawcroft@linaro.org, katsuki.uwatoko@toshiba.co.jp, libc-ports@sourceware.org Subject: Re: [PATCH] Avoid unnecessary busy loop in __lll_timedlock_wait on ARM. References: <20130209.014909.573423212502453699.davem@davemloft.net> In-Reply-To: <20130209.014909.573423212502453699.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: 2013-02/txt/msg00023.txt.bz2 On 02/09/2013 01:49 AM, David Miller wrote: > From: "Carlos O'Donell" > Date: Fri, 8 Feb 2013 23:18:42 -0500 > >> I see that sparc32 also has a unique copy of lowlevellock.c Why the >> use of *_24_* atomic primitives? Faster? > > On pre-v9 32-bit sparc, we lack any usable atomic compare and > swap. > > All we have is an 8-bit spinlock. > > So we implement things in a 32-bit word which is composed of a 24-bit > counter and an 8-bit lock. Thus a futex on sparc looks like this? struct futex { union { int whole; struct { char lock; char value[3]; } __split; } __futex; }; With only 24-bits for the value? I'll have to remember pre-v9 sparc only has 24-bits there. I'd seen the *other* sparc pre-v9 implementation that used 64 global locks per-library and that seemed signal unsafe and prone to deadlocks. How do you deal with the FUTEX_WAITERS/FUTEX_OWNER_DIED bits that are set in the high bits of the word? Or a tid that is 26-bits (FUTEX_TID_MASK)? Cheers, Carlos.