This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

arch maintainers: RFC on spinlock refactoring


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).
* 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.

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

alpha:
* Can we just use plain atomics instead of the custom code?

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

tile:
* Contains custom back-off implementation.  We should discuss this
separately.
* Does CAS always bring in the cache line in exclusive state?  I guess
it doesn't?
* I suppose atomic_exchange can't be replaced with atomic_store?  Should
this be a flag so that this can be included in the generic code?
* What about trylock?  Keep it or use generic?

powerpc:
* I believe we should create versions of the atomic operations that have
MUTEX_HINT_ACQ set.  We started to discuss this a while ago, but this
died off.  We should pick up this thread again.

x86_64, i386:
* We should move to the generic code.  Confirming that there are no
performance regressions would be good.  As soon as generic spinlock adds
back-off, generic should perform better under contention.

ia64:
* Move to generic code.  Check that the back-off instruction is exposed
through the atomics interface.

sh:
* Use generic spinlock?

sparc:
* sparc64/sparcv9: Use generic spinlock? 
* sparc32 pre-v9: ?





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]