[Development] Maintainer changes to review: QMutex optimisations

Olivier Goffart olivier at woboq.com
Sun Aug 26 18:23:48 CEST 2012


On Sunday 26 August 2012 15:47:31 Thiago Macieira wrote:
> On domingo, 26 de agosto de 2012 15.44.05, Thiago Macieira wrote:
> > With a Double CAS, it might be possible to do that for the Windows and Mac
> > semaphore solutions. PThread also allows for static initialisation, but it
> > requires a destruction call if the mutex is used
> 
> And all of this is so we don't have to run a destructor... That's why I'm
> saying that we're imposing constraints on the much-more-often used QMutex so
> that the less-often QBasicMutex can exist.

This statement is not correct. The goal of the whole thing is that we have a 
cheap QMutex.  The existence of QBasicMutex is not a goal, just a nice side 
effect of the design of QMutex.

The design of the current QMutex is so that it is free in the non contended 
case, so we can use in libraries and it does not have much overhead on code 
that we want to make thread safe, but will most likely not be used with 
threads.
You can also have a lot of mutex and increase the granularity.
But QMutex can of course be used in a contended case. There will be a small 
overhead, but it should be neglectible compared to the cost of blocking.

Then, QBasicMutex was built out of QMutex, in order to improve further the 
global mutexes.

I hope you understand my point of view here. QBasicMutex is to QMutex what 
QBasicAtomicInt is to QAtomicInt. It's the same, but one is POD.

But with your changes, you seem to think that QMutex and QBasicMutex two 
different classes with different API.

You are also implying that a cheap memory overhead, and cheap uncontended 
locking are not worth it. Based on an extreme benchmark that is way too 
contended to be usefull. 
	
-- 
Olivier

Woboq - Qt services and support - http://woboq.com



More information about the Development mailing list