[PATCH v2 3/4] Move libio lock single-thread optimization to generic libc-lock (BZ #27842)

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

Hi Adhemerval,

/* Lock the recursive named lock variable.  */
#define __libc_lock_lock_recursive(NAME) \
  do {                                                                        \
    void *self = THREAD_SELF;                                                 \
    if ((NAME).owner != self)                                                 \
      {									      \
	if (SINGLE_THREAD_P)                                                  \
	  (NAME).lock = 1;						      \
        else								      \
           lll_lock ((NAME).lock, LLL_PRIVATE);                               \
        (NAME).owner = self;                                                  \
      }                                                                       \
    ++(NAME).cnt;                                                             \
  } while (0)


The issue is that recursive locks are very expensive. Even with the single thread
optimization there are still 5 memory accesses just to take a free lock! While I'm in
favour of improving locks like above, I think removing the single threaded optimizations
from libio will cause major performance regressions in getc, putc, feof etc.

Basically doing single threaded optimizations at the highest level will always be faster
than doing it at the lock level. That doesn't mean optimizing general locks isn't useful,
however all it does is reduce the need to add single threaded optimizations rather than
make them completely unnecessary.

> Or if we are bounded to keep the current practice to check for single-thread and
> skip locks internally.  It would be good to consolidate all the internal lock
> usage and have the single-thread lock optimizations on all locks, not only on
> pthread_mutex_lock.

Yes, we should have single threaded optimization on all locks, including __libc_lock_lock.
Recursive locks can be optimized both for single threaded and multi-threaded case.
I'm wondering whether we could use the lock variable itself to store useful data (since most
ISAs will allow 64 bits). Then all you need to check is the .lock field and only if it is already
taken do the extra checks for ownership and incrementing recursion counter.

Cheers,
Wilco