[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Mutz, Marc]

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