[Development] QMutex with pthread on Linux

Thiago Macieira thiago.macieira at intel.com
Wed Aug 22 10:20:24 CEST 2012


On quarta-feira, 22 de agosto de 2012 07.00.05, lars.knoll at nokia.com wrote:
> > When contention happens a lot, the performance is awful. I've measured 
> > anything from 100% slower to over 1000%.
> 
> Uhhh… is there a reason why it's that much slower than the pthread mutex? A
> factor of 2 to 10 slower is not really what we should have.

QMutex does two things in addition to pthread_mutex_lock:
 a) a loop trying to create and assign a QMutexPrivate
 b) a more expensive wait

a) is the freelist and I have not measured its performance impact yet. It 
could be anywhere from negligible to responsible for almost the entire 
difference

b) the locking and unlocking itself
			pthread					QMutex
locking		pthread_mutex_lock		pthread_mutex_lock
									pthread_cond_wait
									pthread_mutex_unlock

unlocking	pthread_mutex_unlock	pthread_mutex_lock
									pthread_cond_signal
									pthread_mutex_unlock

A pthread_cond_t is a much more complex beast than a mutex, so its use in 
QMutex is definitely going to increase the complexity. That said, I don't 
believe this to be a large contributor. The mutex is retained locked quite 
infrequently and NPTL code is quite efficient in unlocked forms.

What's more, I don't see a way around this. For that reason, I'm focusing on 
rewriting the first part, which I don't understand, is undocumented, complex 
and I have the feeling is also racy. 

I'm inserting a spinlock to protect the QMutexPrivate internals.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120822/b23292c7/attachment.sig>


More information about the Development mailing list