On quarta-feira, 22 de agosto de 2012 07.00.05, [email protected] 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
