On 2019-08-23 10:31, Mutz, Marc via Development wrote:
If that's the case, shouldn't we run, not walk, to replace our internal uses with std::mutex + std::condition_variable to have only one mutex?
Since it _is_ the case, I've sat down and ported QReadWriteLock from QMutex + QWaitCondition to std::mutex and std::condition_variable: https://codereview.qt-project.org/c/qt/qtbase/+/273598
1/8th speed-up in contested write-only cases (readOnly doesn't use the Private class) may not sound much, but seeing as QRWL is an order of magnitude slower than std::shared_mutex in this test (https://codereview.qt-project.org/c/qt/qtbase/+/273595), and with the pending change to get rid of the QHash in there (https://codereview.qt-project.org/c/qt/qtbase/+/185849), the speed-up will become much more pronounced still (my laptop's CPUs are only 50% of the time in C0 when this test executes, for std::shared_mutex, it's more like 90%, which gives you an idea of the efficiency gap that needs, and probably can be, bridged, still).
I think this proves that QWaitCondition not only theoretically (by counting the mutexes) but also practically can no longer be recommended for Qt implementation work.
I also question the usefulness of it in new user code, seeing as we'll probably not go back to backing QMutex by std::mutex just to enjoy the same optimisation std::condition_variable enjoys over std::condition_variable_any, which means this class is de-facto deprecated.
So, will we also deprecate it de-jure? Thanks, Marc _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
