Re: New optimized normal-type mutex?

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

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

Am Mittwoch, den 29.07.2015, 20:10 -0400 schrieb Rich Felker:
> On Thu, Jul 30, 2015 at 01:49:20AM +0200, Jens Gustedt wrote:
> > Hm, could you be more specific about where this hurts?
> > 
> > In the code I have there is
> > 
> >         for (;val & lockbit;) {
> >           __syscall(SYS_futex, loc, FUTEX_WAIT, val, 0);
> >           val = atomic_load_explicit(loc, memory_order_consume);
> >         }
> > 
> > so this should be robust against spurious wakeups, no?
> 
> The problem is that futex_wait returns immediately with EAGAIN if
> *loc!=val, which happens very often if *loc is incremented or
> otherwise changed on each arriving waiter.

Yes, sure, it may change. Whether or not this is often may depend, I
don't think we can easily make a quantitative statement, here.

In the case of atomics the critical section is extremely short, and
the count, if it varies so much, should have a bit stabilized during
the spinlock phase before coming to the futex part. That futex part is
really only a last resort for the rare case that the thread that is
holding the lock has been descheduled in the middle.

My current test case is having X threads hammer on one single
location, X being up to some hundred. On my 2x2 hyperthreaded CPU for
a reasonable number of threads (X = 16 or 32) I have an overall
performance improvement of 30%, say, when using my version of the lock
instead of the original musl one. The point of inversion where the
original musl lock is better is at about 200 threads.

I'll see how I can get hold on occurrence statistics of the different
phases without being too intrusive (which would change the
scheduling).

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: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]