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]

Re: [PATCH] Unify pthread_spin_[try]lock implementations.


> 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


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