Re: [PATCH 2/2] Add single-threaded fast path to rand()

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi Cristian,

> So the generalized lock-omitting code in __libc_lock_lock didn't
> flew..

There were some comments on it. One issue is that it would affect
practically every lock in GLIBC, thus adding code and branches even for
locks that don't benefit from single-threaded optimization.

Hence the idea of first sorting out rand() since it is a frequent performance
complaint (unfortunately).

> what a new fast path macro function like (sorry I suck at
> naming things) __libc_maybe_lock_lock that only locks if not single
> thread ?

Yes despite the huge mess of locking macros in use, adding a new set of
macros may be better overall. We could say that the critical section must not
create a new thread itself. This means we can avoid checking the lock value
and compile the lock macro like:

#define __libc_fast_lock(NAME) if (SINGLE_THREAD_P || !__libc_lock_lock (NAME)) {

Cheers,
Wilco