Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h

[ Available lists | Index of cvs-all | Month of Oct 2007 | Week of 29 Oct 2007 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Daniel Eischen <deischen@freebsd.org>
Date
29 Oct 2007 21:19:56
Subject
Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h
Message-ID
Pine.GSO.4.64.0710291712100.19572@sea.ntplx.net


[ Hide this part ]
On Mon, 29 Oct 2007, Kris Kennaway wrote:

> kris 2007-10-29 21:01:47 UTC
>
> FreeBSD src repository
>
> Modified files:
> lib/libthr/thread thr_mutex.c
> lib/libkse/thread thr_mutex.c
> include pthread.h
> Log:
> Add a new "non-portable" mutex type, PTHREAD_MUTEX_ADAPTIVE_NP. This
> is also implemented in glibc and is used by a number of existing
> applications (mysql, firefox, etc).
>
> This mutex type is a default mutex with the additional property that
> it spins briefly when attempting to acquire a contested lock, doing
> trylock operations in userland before entering the kernel to block if
> eventually unsuccessful.
>
> The expectation is that applications requesting this mutex type know
> that the mutex is likely to be only held for very brief periods, so it
> is faster to spin in userland and probably succeed in acquiring the
> mutex, than to enter the kernel and sleep, only to be woken up almost
> immediately. This can help significantly in certain cases when
> pthread mutexes are heavily contended and held for brief durations
> (such as mysql).
>
> Spin up to 200 times before entering the kernel, which represents only
> a few us on modern CPUs. No performance degradation was observed with
> this value and it is sufficient to avoid a large performance drop in
> mysql performance in the heavily contended pthread mutex case.
>
> The libkse implementation is a NOP.

The libkse implementation already spins for a bit. The default
number of spins is 500.

I'm not sure that another mutex type is warranted, the default
mutex implementation should be adaptive I think.

--
DE


Elapsed time: 0.148 seconds