This is a temporary measure to work around an implementation bug on
Integrity: For all other platforms, QtPrivate::condition_variable is
just std::condition_variable. On Integrity, it's a class that wraps
QWaitCondition to provide the interface of std::condition_variable.
This allows the use of std::condition_variable across Qt without
running into the Integrity issue. Once we can depend on an more modern
Integrity toolchain, removing QtPrivate::condition_variable is a
simple mechanical change:
s/QtPrivate::condition_variable/std::condition_variable/g;
s/QtPrivate::mutex/std::mutex/g;
Task-number: QTBUG-78450
Change-Id: I293a99d1cdc48691817b926aa51ecd84556e5e90
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit 319c478603.
Reason for revert: QTBUG-78450
Change-Id: Ifaea83626296508558591d4ff207d4e0c883f841
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
This reverts commit 5859f7d0d9.
Reason for revert: the blocker for qtdeclarative has been merged
(in qtdeclarative/c060f6e765a2f155b38158f2ed73eac4aad37e02).
Change-Id: Ie69cb1567417173f543e88f659658fe03ba28830
Reviewed-by: Liang Qi <liang.qi@qt.io>
It turns out that QWaitCondition is a std::condition_variable_any. The
_any variant works with any mutex type, but requires a native mutex
for the native condition variable. So, QWaitCondition and
std::condition_variable_any both require two different mutexes: the
one the user passes in, and an internal one.
std::condition_variable, however, only works with std::mutex, and
since both are backed by the native API, condition_variable can use
the mutex passed in by the user instead of having to use an internal
one.
So, port from 2 × QWaitCondition + QMutex (2 × native cond + 2 ×
native mutex + Qt mutex) to std::condition_variable + std::mutex (2 ×
native cond + native mutex), shaving the overhead of two additional
mutexes (one Qt, one native) as well as the memory allocation
performed by QWaitCondition (for its Private).
Speeds up the writeOnly case by ~1/8th:
PASS : tst_QReadWriteLock::writeOnly(QReadWriteLock)
RESULT : tst_QReadWriteLock::writeOnly():"QReadWriteLock":
- 39,703 msecs per iteration (total: 39,703, iterations: 1)
+ 34,950 msecs per iteration (total: 34,950, iterations: 1)
Change-Id: I196cb13a27242fc1cb99723dfab5b2e5f8522143
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Most of these are unique_locks because they call QWaitCondition::wait()
and it doesn't feel right to use qt_scoped_lock if the lock is dropped
within the scope.
Change-Id: I506eede63008dad135c21112e578da4f7684e528
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
- use qExchange() in cancel()
- use cancel() instead of manual pointer manipulations in the move ctor
Change-Id: Ica3a3a1e339500c5e5a0c0646e7a95c7c5d435db
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
- add missing explicit
- drop static from member functions that aren't static in the regular version
(ie. all functions)
As a drive-by, remove redundant inline keyword where it doesn't cause
wanton inconsistency with surrounding code.
Change-Id: I5aed73c3afa85d98d97b57c2c1874b1a5e664960
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We can't use qt_scoped_lock/qt_unique_lock here, so port to
std::unique_lock and std::lock_guard for now.
This is in preparation of deprecating QMutexLocker in favor
of std::unique_lock and std::scoped_lock.
In QFutureInterface, change the return type of mutex() from
QMutex* to QMutex&, so we don't need to deref when passing
to std::lock_guard. We need to keep the old method around
for BC reasons, so the new one needs an artificial function
argument for disambiguation. This will vanish come Qt 6.
Change-Id: I1a0f0205952a249512ec2dbd3f0f48dd209b1636
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
With C++11, all compilers support thread_local, which replaces the non-
standardized __thread attribute as a storage class.
The storage class was specifically introduced so that applications do
not have to deal with pthread APIs for TLS key management. We still
need to have some of that logic for adopting foreign threads, but we
can rely on thread_local so that we get a fast implementation of
QThread::currentThread() on all platforms.
Change-Id: Iba2b35d014044c4ab317a0e127c5d1f1fa4ecd4a
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Now that QRecursiveMutex is getting split off of QMutex, QMutexLocker
will stop working on QRecursiveMutex once the split has been finalized
in Qt 6.
Even today, QMutexLocker contains casts from QBasicMutex to QMutex
that some reviewers are uncomfortable with. One way to carry
QMutexLocker forward is to template it on the mutex type, possibly
with aliases like QBasicMutexLocker and QRecursiveMutexLocker. C++17
code would then not require a port, thanks to CTAD.
But we have the problem now, and we can't template QMutexLocker in Qt 5.
The alternative is to look at std and realize that they have surpassed
QMutexLocker in expressiveness already. A scoped_lock cannot be
unlocked again, a unique_lock can be moved around. QMutexLocker
doesn't do either. The only "problem" is that the std lock classes are
already templates, but we can't, yet, rely on C++17 CTAD to make them
look as if they weren't.
So, prepare for a future with C++17 CTAD by writing factory functions,
qt_scoped_lock and qt_unique_lock, which will later port mechanically
to their C++17 equivalents (mostly).
The functions are added to a new private qlocking_p.h becauee we don't
want to make them public. These are for use in Qt's own implementation,
or for users that don't care about compatibility and will not mind them
to be removed once we depend on C++17. Originally, I planned to use
qmutex_p.h instead, but that header is not self-contained and causes
build errors when we started to include it into libraries other than
QtCore.
Regarding the return value of qt_scoped_lock: Ideally, we'd like to
return a std::scoped_lock, but two things stand in the way: First,
scoped_lock was only added in C++17 (we fall back to lock_guard if
scoped_lock is not available). Second, returning one from a function
requires C++17 guaranteed copy elision, because neither scoped_lock
not lock_guard have a copy ctor. In order for code not to come to
depend on a particular lock class, we return any of lock_guard,
unique_lock or scoped_guard, depending on what the compiler supports,
and therefore wrap the functions in the unnamed namespace to avoid
running into ODR if (private) headers are used from different projects
(autotests, e.g.). By the time we can drop them, however, qt_*_lock
will be semantically 100% identical to their replacements.
Port some initial users.
Change-Id: I2a208ef2a4a533ee8e675812273986460e6b4d00
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The array of QAtomicPointer<QMutex> can be initialized using relaxed
stores of nullptr, since nullptr is the whole data. But once we store
an actual QMutex pointer in the array, we need to publish the indirect
data thus created. We did this, with testAndSetRelease(); what was
missing was a corresponding acquire fence on load, without which there
is no happens-before relationship between the writes performed by the
QMutex ctor and the reads performed by a subsequent mutex.lock(), say,
on the same data.
Fix by adding acquire fences to all loads. That includes the dtor,
since mutexes may have been created in different threads, and never
been imported into this_thread before the dtor is running.
As a drive-by, return a new'ed QMutex that was successfully installed
directly to the caller, without again going through a load-acquire.
Fixes: QTBUG-59164
Change-Id: Ia25d205b1127c8c4de0979cef997d1a88123c5c3
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 65b8f59e04)
(cherry picked from commit da38f0d691d9d7eacfac5fbcbd47b887bd59bd39)
If this function is called by multiple threads, more than one could
reach the mutex locking and call TlsAlloc(), but only the last one would
save the data. The others would be leaked and, worse, be used by those
other threads.
[ChangeLog][QtCore][QObject] Fixed a resource leak caused by a race
condition if multiple QObjects were created at the same time, for the
first time in an application, from multiple threads (implies threads not
started with QThread).
Fixes: QTBUG-77238
Change-Id: Ife213d861bb14c1787e1fffd15b63a5818bcc807
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
These were hidden in !QT_CONFIG(thread) code. The irony!
This patch does not change the semantics of the operations. It
just makes the implicit operations explicit.
Any fixes or optimizations are left for follow-up patches, if any.
Change-Id: I014eb71745532dae2efe7963aa87321f61b1bd7a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Also reduce the pool size from 131 to 17, and use QBasicMutex
instead of recursive ones.
Change-Id: I3bf0374cce5ff2c07427070aba6128a22c9b70e4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Move the recursive mutex use case out of QMutex into a separate class,
unsurprisingly called QRecursiveMutex. As an immediate benefit, 90% of
the QMutex users now enjoy a constexpr QMutex ctor.
This change prepares for a real split in Qt 6, so that both use-cases
are no longer bundled up in one class.
[ChangeLog][QtCore][QMutex] Added QRecursiveMutex as a replacement of
QMutex(QMutex::Recursive).
Change-Id: I79b8724e8a8ee65e4bd0f06acd76103fe4197b8c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The default stack size is too small on RTEMS.
Qt uses threads internally and there is no way to change their stack
size.
Change-Id: I94a42c7a70c745f0b50d7051d9320edfabd1e09e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The array of QAtomicPointer<QMutex> can be initialized using relaxed
stores of nullptr, since nullptr is the whole data. But once we store
an actual QMutex pointer in the array, we need to publish the indirect
data thus created. We did this, with testAndSetRelease(); what was
missing was a corresponding acquire fence on load, without which there
is no happens-before relationship between the writes performed by the
QMutex ctor and the reads performed by a subsequent mutex.lock(), say,
on the same data.
Fix by adding acquire fences to all loads. That includes the dtor,
since mutexes may have been created in different threads, and never
been imported into this_thread before the dtor is running.
As a drive-by, return a new'ed QMutex that was successfully installed
directly to the caller, without again going through a load-acquire.
Change-Id: Ia25d205b1127c8c4de0979cef997d1a88123c5c3
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The old code used the implicit conversions from QAtomicPointer<T> to T*
and vice versa. The semantics of these differ from the ones std::atomic
uses, so we're going to deprecate these, like we did for load() and
store(), too.
This patch fixex some users of these APIs before we deprecate them.
Change-Id: I0a88bb1c359392538bb64b511bfc62381a56a468
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit 79bdc7cf1d.
We haven't ported every usages to loadRelaxed() / storeRelaxed() yet.
And warning as error is enabled in dev. We will revert this change
when new qt5 baseline got integrated.
Task-number: QTBUG-76611
Change-Id: I5b1f608fefbaca481311f376f22718f2c5047106
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Tell people to move to loadRelaxed() / storeRelaxed(), now that
we have them.
[ChangeLog][QtCore][QAtomicInteger] The load() / store() functions
have been deprecated in favor of loadRelaxed() / storeRelaxed().
[ChangeLog][QtCore][QAtomicPointer] The load() / store() functions
have been deprecated in favor of loadRelaxed() / storeRelaxed().
Change-Id: If7a31db2f90fce4a7605a2377067e86990646f48
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Semi-automated, just needed ~20 manual fixes:
$ find \( -iname \*.cpp -or -iname \*.h \) -exec perl -pe 's/(\.|->)load\(\)/$1loadRelaxed\(\)/g' -i \{\} +
$ find \( -iname \*.cpp -or -iname \*.h \) -exec perl -pe 's/(\.|->)store\(/$1storeRelaxed\(/g' -i \{\} +
It can be easily improved (e.g. for store check that there are no commas
after the opening parens). The most common offender is QLibrary::load,
and some code using std::atomic directly.
Change-Id: I07c38a3c8ed32c924ef4999e85c7e45cf48f0f6c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
navigator.hardwareConcurrency can be accessed from
the main thread only. Read and cache the value on
QCoreApplication initialization.
Change-Id: I731f7f356ce106c7107977783d4b763326af06b6
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
qatomic.h included qbasicatomic.h which included qatomic.h.
Due to a define in qbasicatomic.h, the definitions from QAtomic would
change depending on which was included first. Fortunately qbasicatomic
does not need qatomic.h so the include can be removed.
Change-Id: I086009f2e16a6e20b2b76fc6b3bf66a343414206
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This enables overriding the macro so that it translates
to 'None' in the Qt for Python context.
Change-Id: Ib3cecf57eeb0405a1929309b71e9f012a07f11cf
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Set name for pthread instead of "name too long" for easier tracking.
Change-Id: Iab22cbeac01277e4dc1325399c7892de2e5bd551
Reviewed-by: Timo Aarnipuro <timo.aarnipuro@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Wait for the result at the target index if the future
is running and the iterator index is past the current
result count.
Determine if there is a result at the target index
after waitForResult() returns, and return -1/end if
not.
Also support decrementing the end iterator. In this
case wait for the future to finish in order to get
the final result count.
Task-number: QTBUG-59811
Change-Id: I8fcc711bab2e72c3c5196a55b794d25e18bb324d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Plain load() / store() have already relaxed semantics. This
can be surprising -- std::atomic::load()/store() are actually
sequentially consistent -- and introduce a pain point
if someone wants to move from Qt atomics to std:: atomics.
So just add a suffix to the functions to clarify what's the
memory ordering involved with them.
The Ops::load / ::store are temporarily left in, because other
modules depends on them. We need to port those modules away,
then they can go (it's private API anyhow).
Similarly, not deprecating anything yet, except for marking
obsolete in the docs; there's a lot of code around using
load() / store() that needs to be ported first.
[ChangeLog][QtCore][QAtomicInteger] Added loadRelaxed() and
storeRelaxed(), to be used as replacements of load() / store().
[ChangeLog][QtCore][QAtomicPointer] Added loadRelaxed() and
storeRelaxed(), to be used as replacements of load() / store().
Change-Id: Iab0a78885050379e3740f0b039ba2bef28ce3bd2
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows QtDeclarative examples to build.
Change-Id: Icd20304f76f8ba15c94eaf01b9fcd7b151b16146
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Replace null and '\c nullptr' with \nullptr in the documentation.
Change-Id: Ib9e0cfc2eb2830b213e6523773603d56180b0998
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The timeout will never be larger than numeric_limits<quint64>::max(),
especially on platforms with 32-bit longs.
Instead, test if the timeout is exactly numeric_limits<unsigned long>::max(),
which matches the ULONG_MAX value which is documented
to indicate no timeout.
Change-Id: Ib663eddb5703797c50c04fd4eae60bd64f379d1c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Marc Mutz
Qt Forward Merge Bot
Jani Heikkinen
Giuseppe D'Angelo
Liang Qi
Volker Hilsheimer
Thiago Macieira
Tasuku Suzuki
Mikhail Svetkin
Morten Johan Sørvig
Allan Sandfeld Jensen
Venugopal Shivashankar
Paul Wicking
Janne Koskinen
Lorn Potter
Christian Ehrlicher
Alessandro Portale