Re: arch maintainers: RFC on spinlock refactoring

[Carlos O'Donell <carlos at redhat dot com>]

On 02/18/2017 01:23 PM, Torvald Riegel wrote:
> We want to refactor the spinlock code (ie, pthread_spin* functions); the
> goal is to improve the generic implementation and use it for as many
> architectures as possible.  Stefan Liebler has started this work on the
> s390 side.
> 
> I'd like to have input on some arch-specific questions from some of you.
> 
> Roughly, I think we should
> * Finish Stefan's first patch that brings the generic spinlock code into
> a good shape.
> * Add some properties of atomic operations to each arch's
> atomic-machine.h; for now, we're considering 1) whether atomic
> read-modify-writes are implemented through CAS and 2) whether a CAS
> always brings in the cache line in an exclusive state (ie, even when the
> CAS would fail).

OK.

> * Move as many architectures as we can without detailed review to the
> generic spinlock.
> * Integrate the spinlock code of the remaining archs; this may require
> either extending the generic spinlock code (eg, if the arch comes with
> more advanced spinning) or improving the atomics of those archs.
> * Improve the back-off strategy; use microbenchmarks to justify changes.

OK.

> archs that should be able to simply use the generic spinlock after
> Stefan's first patch has been applied:
> aarch64, microblaze, arm, m68k, s390, mips, nios2

> hppa:
> * I suppose we can use generic once we've fixed the atomics (ie, make
> atomic stores use the kernel atomics emulation too)?

Yes. My outstanding question is about pthread_spin_init() and the current
hppa implementation which uses atomic_exchange_rel (lock, 0) because it is
required to ensure the kernel helper is used and to ensure a true happens-before.

The nptl generic implementation just has *lock = 0.

-- 
Cheers,
Carlos.