[Mesa-dev] [PATCH] mesa: Add new fast mtx_t mutex type for basic use cases

Emil Velikov emil.l.velikov at gmail.com
Thu Jan 29 06:36:12 PST 2015


On 28/01/15 05:08, Kristian Høgsberg wrote:
> While modern pthread mutexes are very fast, they still incur a call to an
> external DSO and overhead of the generality and features of pthread mutexes.
> Most mutexes in mesa only needs lock/unlock, and the idea here is that we can
> inline the atomic operation and make the fast case just two intructions.
> Mutexes are subtle and finicky to implement, so we carefully copy the
> implementation from Ulrich Dreppers well-written and well-reviewed paper:
> 
>   "Futexes Are Tricky"
>   http://www.akkadia.org/drepper/futex.pdf
> 
> We implement "mutex3", which gives us a mutex that has no syscalls on
> uncontended lock or unlock.  Further, the uncontended case boils down to a
> cmpxchg and an untaken branch and the uncontended unlock is just a locked decr
> and an untaken branch.  We use __builtin_expect() to indicate that contention
> is unlikely so that gcc will put the contention code out of the main code
> flow.
> 
> A fast mutex only supports lock/unlock, can't be recursive or used with
> condition variables.  We keep the pthread mutex implementation around as
> full_mtx_t for the few places where we use condition variables or recursive
> locking.  For platforms or compilers where futex and atomics aren't available,
> mtx_t falls back to the pthread mutex.
> 
> The pthread mutex lock/unlock overhead shows up on benchmarks for CPU bound
> applications.  Most CPU bound cases are helped and some of our internal
> bind_buffer_object heavy benchmarks gain up to 10%.
> 
Hi Kristian,

Can I humbly ask that you split this into two patches - one that
introduces the new functions/struct and another one that uses them ?
This way it'll be easier if/when things go crazy.

Also the patch seems to wonder between posix and win32
+ typedef full_mtx_t mtx_t;

and
+ typedef mtx_t fast_mtx_t;

Looks like a left over from the "should I rename XX variables to fast*
or just one to full*" moment :)


Thanks
Emil



More information about the mesa-dev mailing list