[Development] Maintainer changes to review: QMutex optimisations

[Thiago Macieira]

On domingo, 26 de agosto de 2012 18.23.48, Olivier Goffart wrote:
> 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.

Not completely.

It's missing a Q_BASIC_MUTEX_INITIALIZER. For that reason, QBasicMutex can 
only be used as a global or static variable, never on the heap or as part of a 
class.

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

No, they are similar API. But it seems to me we're constraining QMutex so that 
we can have a POD mutex. Unfortunately, except for Linux futexes, there is no 
such thing as POD mutexes with no initialisation and no destruction. All other 
implementations (Windows pre-8, Mac, pthread) require initialisation and 
destruction.

> 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.

No, I'm not implying that.

Cheap uncontended locking are definitely goals. We've done that in Qt 4 to 
great success.

What I'm challenging is that the overhead for contended is not as cheap as the 
current design expects it to be. The current design strongly disfavours 
extremely-threaded scenarios. The contention doesn't happen only on a single 
mutex, but also when two unrelated mutexes are contending, as there's a shared 
structure they must access.

In that light, I have to wonder whether paying the cost of initialisation and 
destruction wouldn't be more worth it.

-- 
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/20120826/70ee7141/attachment.sig>