Re: [PATCH] a new lock algorithm with lock value and CS counts in the same atomic int

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Hello Rich,

On Sun, 18 Jun 2017 12:04:59 -0400 Rich Felker <dalias@libc.org> wrote:

> > > Is there a reason __wait doesn't work?  
> > 
> > __wait doesn't fit here at all, for instance it manipulates a
> > separate int with waiters count.  
> 
> It accepts a null pointer for the waiters count, so that it can be
> used in contexts with or without one. Any cost of the additional
> conditional branches is dominated by syscall time.

Looking into it, I don't agree with you, Rich. Even with waiters set
to 0 it would to 100 spins before going into the syscall. This is much
of a waste, here, because we are just comming out of a spin (at the
first iteration) or we did spin around as long as the value was
positive.

I don't see why the cost of 100 spins would be dominated by the
syscall. If I remember correctly, the benchmarks that I made showed
about 10 memory operations for an unsuccessful syscall. This is why
the magic number for the initial spin is set to 10.

It might be benefitial to do a_spin for a while, if we know that CS
that are protected by this lock are really short, just some
cycles. But 100 is a far too big number, and in my benchmarks I found
not much indication of a benefit for it.

If we want code sharing with the rest of musl (which we should) I like
Alexander's idea of a __futexwait inline function much better.


Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]