From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1710 invoked by alias); 16 Aug 2012 12:40:49 -0000 Received: (qmail 1577 invoked by uid 22791); 16 Aug 2012 12:40:44 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,KHOP_THREADED,RCVD_IN_SORBS_WEB,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from usmamail.tilera.com (HELO USMAMAIL.TILERA.COM) (12.216.194.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Aug 2012 12:40:30 +0000 Received: from [192.168.211.54] (209.117.47.251) by USMAExch2.tad.internal.tilera.com (10.3.0.33) with Microsoft SMTP Server id 14.0.694.0; Thu, 16 Aug 2012 08:40:27 -0400 Message-ID: <502CEA39.8050701@tilera.com> Date: Thu, 16 Aug 2012 12:40:00 -0000 From: Chris Metcalf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Torvald Riegel CC: Maxim Kuvyrkov , Roland McGrath , Andrew Haley , David Miller , "Joseph S. Myers" , Richard Sandiford , , GLIBC Devel 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> <4FFD3CD9.4030206@redhat.com> <84304C03-6A49-4263-9016-05486EDC0E98@codesourcery.com> <4FFD4114.9000806@redhat.com> <20120711112235.B28CA2C099@topped-with-meat.com> <7FBB4F87-9FF3-4239-818F-5A38C8094011@codesourcery.com> <20120725181300.DD1812C0B5@topped-with-meat.com> <36A2FFD8-0C98-4AB6-8C64-2EEC5CC67A63@codesourcery.com> <1345112457.3083.217.camel@triegel.csb> In-Reply-To: <1345112457.3083.217.camel@triegel.csb> Content-Type: text/plain; charset="UTF-8" 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-08/txt/msg00141.txt.bz2 On 8/16/2012 6:20 AM, Torvald Riegel wrote: >> while Teil will use -1. > Is there a plan to include a back-off component in this generic spin > lock? (-1 would spin forever, but not do back-off.) Certainly one could imagine parameterizing a back-off loop with starting point and ending point for a bounded exponential backoff calling atomic_delay() in the loop (as Roland proposed a while back). I expect something like that would be usable for the tile architecture. But my instinct is that it is too architecture-dependent to try to get this right enough for all platforms, and the basic idea of a spinlock is simple enough for each architecture to express that it's probably not a good tradeoff. In fact, I'm a little concerned that the proposed spinlock is overdesigned as it is, with every platform providing the same macro parameter to conditionalize it such that it looks exactly the same. I'd probably rather see a straight-up ARM implementation, and then just write it such that HPPA, M68K, and MIPS can #include the ARM version if they want to, rather than trying to make something that seems more complex than necessary for the truly generic implementation, but not complex enough to really be usable by every implementation. But: bike-shedding. If the maintainers of those platforms are happy, that's fine with me. :-) -- Chris Metcalf, Tilera Corp. http://www.tilera.com