glibc pthreads and optimized locks

glibc pthreads and optimized locks

[dumblob]

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).

Thanks,

dumblob

Re: glibc pthreads and optimized locks

[Adhemerval Zanella]

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.