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