From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29829 invoked by alias); 25 Jul 2012 20:22:45 -0000 Received: (qmail 29809 invoked by uid 22791); 25 Jul 2012 20:22:44 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,TW_PX X-Spam-Check-By: sourceware.org Received: from toast.topped-with-meat.com (HELO topped-with-meat.com) (204.197.218.159) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jul 2012 20:22:27 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id 560582C0DA; Wed, 25 Jul 2012 13:22:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Chris Metcalf Cc: Maxim Kuvyrkov , Andrew Haley , David Miller , , , , Subject: Re: [PATCH] Unify pthread_spin_[try]lock implementations. In-Reply-To: Chris Metcalf's message of Wednesday, 25 July 2012 15:03:46 -0400 <50104312.70205@tilera.com> 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> <50104312.70205@tilera.com> Message-Id: <20120725202226.560582C0DA@topped-with-meat.com> Date: Wed, 25 Jul 2012 20:22:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.0 cv=e8d9udV/ c=1 sm=1 a=IOX5nZC-PoQA:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=14OXPxybAAAA:8 a=CCpqsmhAAAAA:8 a=0yJfGZRPav2yGmUSu3AA:9 a=CjuIK1q_8ugA:10 a=NPPiaBLUxcIA:10 a=WkljmVdYkabdwxfqvArNOQ==:117 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/msg00053.txt.bz2 > The tile architecture is unlikely to use this generic version no matter > what; see http://sourceware.org/ml/libc-ports/2012-07/msg00030.html for the > details, but the primary point is that in a mesh-based architecture it's a > bad idea to ever end up in a situation where all the cores can be spinning > issues loads or cmpxchg as fast as they can, so some kind of backoff is > necessary. I had read that before but only noticed the explanation that the plain reads were bad. (Hence in my suggestion you'd share the code but with a #define that means the loop of plain reads would be elided entirely at compile time by constant folding.) What kind of "backoff" do you mean? It's probably appropriate on every machine to use "atomic_delay ();" inside such loops. Thanks, Roland