Re: [Threads-devel] pthreads_rwlock vs shared_mutex

Subject: Re: [Threads-devel] pthreads_rwlock vs shared_mutex
From: Jaak Ristioja (jaak.ristioja_at_[hidden])
Date: 2014-02-04 03:07:49

On 04.02.2014 01:55, Nathan Rosenblum wrote:
>>
>> Apologies if this is a question that gets asked ad nauseum on this list,
>> but why is the shared_mutex implementation not a wrapper for pthread_rwlock
>> on pthreads-based systems? I observe significantly better performance under
>> concurrent reader access when using the pthreads implementation compared to
>> acquiring a reader lock on shared_mutex, particularly on OSX where the cost
>> of a contended pthread_mutex is extremely high (a short-hold,
>> high-utilization, mostly-read shared_mutex on that platform effectively
>> serializes access).
>>
>>
> Answering my own question: presumably because absent platform-specific
> extensions like Linux's PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP,
> pthread_rwlock is write-starving. Is there interest in implementing
> platform-specific optimization that uses these locks when doing so does not
> change the semantics (e.g. on Linux w/ NPTL)?

My experience is that boost::shared_mutex is also write-starving
(regardless of what the Boost documentation says about its fairness). If
I remember correctly then last I checked the source, boost::shared_mutex
appears to use a regular mutex internally in a manner which makes it
non-fair.

We've experienced this write starvation mostly on NUMA systems running
Centos 6.4. On the other hand, the tbb::queuing_rw_mutex from Intel
Threading Building Blocks actually does appear to be fair as the
documentation says.

Best regards,
Jaak