Re: glibc pthreads and optimized locks

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 07/06/2021 10:30, dumblob via Libc-help wrote:
> Dear glibc experts,
> 
> Does anybody know whether glibc pthreads implement the fast lock
> algorithms as https://github.com/AlexeyAB/object_threadsafe does?
> 
> A detailed description of these algorithms is in
> https://www.codeproject.com/Articles/1183423/We-Make-a-std-shared-mutex-10-Times-Faster
> and some more optimizations in
> https://www.codeproject.com/Articles/1183446/Thread-safe-std-map-with-the-speed-of-lock-free-ma
> . Btw. I'm aware these articles discuss C++, but the same principles
> apply to locks in C.
> 
> I'm asking because pthreads are known to be rather slower in general
> and if such optimized variants of locks are not implemented, I'll
> propose implementing them in few specific apps which would benefit
> from the optimizations (e.g. the main implementation of the V
> language).

I haven't read al the links in details (the C++ code is specially quite 
hard to follow...), but as fair as I know the std::shared_ptr (and
this alternate implementation) maps more directly to pthread_rwlock_t
instead of pthread_mutex_t.

Torvald's Riegel optimized back it on glibc 2.25 and there were a couple 
of fixed back then.  He optimized the fast path so a read lock requires
only a single atomic addition if the lock is or was previously acquired 
by other readers while releasing the lock is a single CAS if there are 
no concurrent writers.  The main constraint is the pthread_rwlock_t is
it shall follow POSIX requirements regarding memory semantic, from the
implementation comment:

| /* A reader--writer lock that fulfills the POSIX requirements (but operations
|   on this lock are not necessarily full barriers, as one may interpret the
|   POSIX requirement about "synchronizing memory").  All critical sections are
|   in a total order, writers synchronize with prior writers and readers, and
|   readers synchronize with prior writers.

So I would suggest you to first evaluate the std::shared_ptr and this
'fast lock algorithms' against pthread_rwlock_t.  The pthread_rwlock_t
does block by calling futex, so it is not really lock-free.

You might try to provide a pthread_rwlock_t which lock-free, but then
you will need to check if this provides *all* the POSIX requirements.
I am not sure this would be possible without something really clever
and somewhat hacky as rseq support.

Otherwise, I don't think glibc is the correct place to support alternate
locking mechanism (you have multiple specialized libraries such as the
one you referred that I think is a better way to provide it).

One TODO you might want to explore is the use o Hardware Transaction
Memory on pthread_rwlock_t. It was previously supported, but with
Torvald newer implementation it was not added back.