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: PowerPC: libc single-thread lock optimization


On 28-04-2014 18:49, Roland McGrath wrote:
> Heretofore sysdeps/CPU/bits/atomic.h is for pure CPU-based implementations.
> In a few cases there exists a sysdeps/unix/sysv/linux/CPU/bits/atomic.h as
> well because it needs to use kernel support.
>
> This is something somewhere in between: you are not depending directly on
> specific facilities outside the pure CPU facilities; but you are depending
> on library infrastructure and associated assumptions that do not hold in
> the general case of using the atomic macros in arbitrary contexts.
> Furthermore, you are defining SINGLE_THREAD_P to depend on NPTL
> implementation details.  IMHO neither of these things belong in a
> sysdeps/CPU/bits/atomic.h file.
>
> The lowlevellock.h change doesn't have those issues, so I'd suggest you
> send that separately and it should go in easily.
>
>
> Thanks,
> Roland
>
I tend to agree with you, however the x86_64 implementation (sysdeps/x86_64/bits/atomic.h)
itself relies on NPTL definitions (the check using (offsetof (tcbhead_t, multiple_threads)))).
And the idea of changing the atomic.h it to simplify the logic to add this optimization:
instead of changing the macros in lowlevellock.h and other atomic usage, it implements
the optimization on the atomic itself.

I bring this about x86 because usually it is the reference implementation and sometimes puzzles
me that copying the same idea in another platform raise architectural question.  But I concede
that the reference itself maybe had not opted for best solution in first place.

So if I have understand correctly, is the optimization to check for single-thread and opt to
use locks is to focused on lowlevellock solely?  If so, how do you suggest to other archs to 
mimic x86 optimization on atomic.h primitives?  Should other arch follow the x86_64 and
check for __libc_multiple_threads value instead?  This could be a way, however it is redundant
in mostly way: the TCP definition already contains the information required, so there it no
need to keep track of it in another memory reference.  Also, following x86_64 idea, it check
for TCB header information for sysdeps/CPU/bits/atomic.h, but for __libc_multiple_threads
in lowlevellock.h.  Which is correct guideline for other archs? 


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