This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] Unify pthread_spin_[try]lock implementations.
- From: Chris Metcalf <cmetcalf at tilera dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Maxim Kuvyrkov <maxim at codesourcery dot com>, Roland McGrath <roland at hack dot frob dot com>, Andrew Haley <aph at redhat dot com>, David Miller <davem at davemloft dot net>, "Joseph S. Myers" <joseph at codesourcery dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, <libc-ports at sourceware dot org>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 16 Aug 2012 08:40:25 -0400
- Subject: Re: [PATCH] Unify pthread_spin_[try]lock implementations.
- References: <Pine.LNX.4.64.1206282306320.20312@digraph.polyomino.org.uk> <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> <E1DB09C1-0E3E-4088-9793-C0CAB80B5084@codesourcery.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>
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