Those weren't caught for the Qt 6.0 release.
Pick-to: 6.10
Change-Id: I5831d4ad80b7f60d8782fffd6c64ef552f82ad6e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
MSVC exports inline functions, so we're not allowed to remove them. This
is an unlikely problem, though, since it was only called from other
inline functions: if the compiler was inlining content into user code
(as it should), then it would likely have inlined this one too; if
instead the inliner was disabled, then it wouldn't have inlined the
caller either.
Amends commit 1957597aa6bc6ebd8bd1f903389800897411ac5d. Seen in API
review.
Pick-to: 6.10
Task-number: QTBUG-137478
Change-Id: Idd01170c3396c5b6fefefffd748f3335fc42fd79
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
For systems where we know for sure that we're using futexes, this moves
the storing of the nullptr (i.e., the unlocking) from unlockInternal()
up to unlock() itself. Thus, it replaces a compare-and-exchange
operation plus a store operation with a single one: a simpler exchange.
I don't expect measurable gains with this, as the branch into
unlockInternal() still depends on the result of an atomic operation.
Change-Id: I120dbdc21e678f4b858ffffd60e6ee013ffff555
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This says better what it is and I'll use the trait for the unlock
operation.
Pick-to: 6.9
Change-Id: I46752ca2ee71297d77e5fffdddaa193b6c86dbbc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Pass the pointer as a void* to avoid having "QMutexPrivate" in the ABI
that user content calls. To have such a private type in ABI used by
inlines in user code required an ELFIGNORE in qmutex_p.h. This change
removes that need for Qt 7.
We can't add an #ifdef for the comment block because "ignore-next" would
then apply to the #endif line. Therefore, a ### Qt7 comment will have to
suffice. It's harmless if we forget to do it.
Change-Id: I83e6ddaf775e71eacb42fffd5cd6b87527b9c08b
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The default argument staying on the old int overload meant that on
Windows a nullary tryLock() call would need to go through both DLL-
exported functions (int, then QDeadlineTimer) and on non-Windows
platforms, it would hit the out-of-line QDeadlineTimer(qint64)
ctor.
By moving the default argument from the old to the new function, we
reduce the nullary call on Windows from two to one exported functions.
On non-Windows, we make it to hit QDeadlineTimer's constexpr inline
default ctor instead.
Found in API-review.
Amends ff9da1db0b0963f967f45ab430ec40a3051b70b4.
Pick-to: 6.6
Change-Id: Id3e9923cf97ee1673fe05c85c30b5a12531857b3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
std::chrono is still used in the header.
Do not rely on transitive includes, instead include the header
explicitly.
Pick-to: 6.6
Change-Id: If9140499e5dccf0065a4826831d3b83813910318
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Amends 5f531ae2ac873c09deda096d292777422c4dee4d
The overload taking QDeadlineTimer::ForeverConstant was required,
prior to making it an enum class, because the conversion preferred
'int'. It was made an enum class for 6.6 and most overloads were
removed, including the one for QMutex, but QRecursiveMutex was
missed.
Pick-to: 6.6
Change-Id: I4490dd3d7641c06346ea502f10c09915411319ad
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A class-level [[nodiscard]] used to be the only way to get a waring
for code such as
QMutexLocker(&mutex);
with original C++17 means. This was because a few of our compilers
would warn about the presence of [[nodiscard]] on ctors, which is
really the semantics we want: we don't want to prevent users from
passing QMutexLocker out of functions and users of those functions
from ignoring the return value, if they so choose. That should be the
choice of the author of the function returning such types, not ours.
So QUIP-0019 makes class-level [[nodiscard]] conditional on proper
rationale in the user docs (or the commit message in case of private
API). Since none of the existing uses really strikes this author as
particularly convincing, remove them all.
All these classes have gotten Q_NODISCARD_CTOR on all their ctors, so
we continue to provide the same true positive warnings, minus the
false positives when returning from functions, at least on the
majority of compilers (and it's not as if all compilers interpreted a
class-level [[nodiscard]] as a trigger to warn on the initial example
of this commit message).
Task-number: QTBUG-104164
Pick-to: 6.6
Change-Id: I163356486e7c80f9d69bf67023010a88233fe662
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Avoids the implicit cast to int, which then fixes the overloading
problem of QDeadlineTimer with older functions taking an integer with
the number of milliseconds. Without this and the workarounds, an
expression like
waitCondition.wait(&mutex, QDeadlineTimer::Forever);
would be the same as
waitCondition.wait(&mutex, 0);
which is the opposite of "forever".
This means we can remove the overloads added earlier this week in
commits 37f1fb78eeb107d593f9a7bf0491466a1c60e068 (QMutex),
63704529b75f831ffeb965765c10caf09f7883fe (QReadWriteLock), and
37f1fb78eeb107d593f9a7bf0491466a1c60e068 (QSemaphore). I hadn't thought
this solution until noting that QWaitCondition needed the same solution
and then remembering how Qt::Uninitialized was fixed of the same
problem.
Change-Id: I5f7f427ded124479baa6fffd176023ddfb91077d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This removes the last use of QtPrivate::convertToMilliseconds().
Change-Id: I6f518d59e63249ddbf43fffd1759fee2e00d36f4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
This simplifies the code greatly, because we don't need to use
QtPrivate::convertToMilliseconds any more, as QDeadlineTimer has
nanosecond precision.
Internally it becomes simpler too because lockInternal was already using
QDeadlineTimer. I just had to use the parameter instead and update the
two non-futex implementations to take it again. This may even be fixing
a mistake in case sem_timedwait(2) got interrupted.
Change-Id: I6f518d59e63249ddbf43fffd1759fed9f50b3606
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Commit d4b206b246caf9b49110526585693ab629609d99, which split
QRecursiveMutex from QMutex and thus rewrote a lot of the tests, removed
the friendship, but not the forward-declaration.
Pick-to: 6.5 6.2
Change-Id: I6f518d59e63249ddbf43fffd1759d28f1547ec9f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The testAndSet operation is expensive if the lock is contended:
attempting to CAS that lock will cause the cacheline containing the lock
to be brought to the current CPU's most local cache in exclusive mode,
which in turn causes the CPU that has the lock to stall when it attempts
to release it. That's not desirable if we were just trying an untimed
tryLock*.
In the case of timed, contended tryLocks or unconditional locks, we
still need to perform an atomic operation to indicate we're about to
wait. For that case, this patch reduces the minimum number of atomic
operations from 2 to 1, which is a gain even in the case where no other
thread has changed the lock status at all. In case they have, either by
more threads attempting to lock or by the one that has the lock
unlocking it, this avoids the cacheline bouncing around between the
multiple CPUs between those two atomic operations. For QMutex, that
second atomic is a fetchAndStore, not testAndSet.
The above explanation is valid for architectures with Compare-And-Swap
instructions, such as x86 and ARMv8.1. For architectures using Load
Linked/Store Conditional instructions, the explanation doesn't apply but
the benefits still should because we avoid the expense of the LL.
See similar change to pthread_mutex_lock in
https://sourceware.org/git/?p=glibc.git;a=commit;h=d672a98a1af106bd68deb15576710cd61363f7a6
Change-Id: I3d728c4197df49169066fffd1756dcc26b2cf5f3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
[ChangeLog][QtCore] Introduced Q_NODISCARD_CTOR which resolves to
[[nodiscard]] attribute for constructors on compilers that support
it, and does nothing on other compilers.
Using [[nodiscard]] attribute on a constructor is a C++20 feature,
however in practice it is supported on most of the compilers that
we use in Qt 6. Clang generates a [-Wunused-value] warning, GCC
and MinGW generate a [-Wunused-result] warnings, and MSVC
generates a C4834 warning.
However, there are some exceptions.
The Integrity compiler provides the following warning:
"tst_qglobal.cpp", line 699: warning #3435-D:
the "nodiscard" attribute doesn't apply to constructors,
destructors, or routines with void return type
[[nodiscard]] explicit Test(int val) : m_val(val) {}
The QNX compiler (QCC 8.3.0) and GCC 9.3.1 on OpenSUSE generate
the [-Wattributes] warning:
tst_qglobal.cpp: In member function
'void tst_QGlobal::nodiscardConstructor()':
tst_qglobal.cpp:699:44: warning: 'nodiscard' attribute applied to
'tst_QGlobal::nodiscardConstructor()::Test::Test(int)' with void
return type [-Wattributes]
[[nodiscard]] explicit Test(int val) : m_val(val) {}
These warnings will lead to build failures when compiled with
-warnings-are-errors flag, so for these compilers the macro
does not do anything.
An attempt to use __attribute__((__warn_unused_result__)) was
also unsuccessful on these compilers, so this patch goes for
an easy solution, and simply checks
__has_cpp_attribute(nodiscard) >= 201907L
to decide if the attribute is supported or not.
This commit also introduces a syntax-only test, and also applies
the new macro to QMutexLocker, because not all platforms in the
CI build and run unit tests.
Fixes: QTBUG-104161
Change-Id: Ib4230661a5ad5e8af0d67b21b034486ebcd67562
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
To allow the user to customize the C++ code that QDoc sees, so as to be
able to work-around some limitations on QDoc itself, QDoc defines two
symbols: Q_QDOC and Q_CLANG_QDOC, both of which are "true" during an
entire execution of QDoc.
At a certain point in time, QDoc allowed the user the choice between a
custom C++ parser and a Clang based one.
The Q_QDOC symbol would always be defined while the Q_CLANG_QDOC symbol
would be defined only when the Clang based parser was chosen.
In more recent times, QDoc always uses a Clang based parser, such that
both Q_CLANG_QDOC and Q_QDOC are always defined, making them equivalent.
To avoid using different symbols, and the possible confusion and
fragmentation that derives from it, all usages of Q_CLANG_QDOC are now
replaced by the equivalent usages of Q_QDOC.
Change-Id: I5810abb9ad1016a4c5bbea99acd03381b8514b3f
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Platforms where we use futex do not allocate.
Windows gained support in 6.2, but the noexcept macro was missed.
Amends 91f6460aff0a6ab5142f16d5f4fc1f559ca1c325
Change-Id: I76da48fbaac5749fdec4ec76de6a0ff891b78442
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
__has_include(<chrono>) is always true, because C++11 chrono include
is required since 6.0.
Pick-to: 6.4 6.3 6.2
Change-Id: I50cb92571bf4f1f86e2f3f2b5f486dd3c3f30f4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The Q(Basic)Mutex fast paths are entirely inline in the caller, which
means we need to annotate its operations directly or TSAN doesn't know
what's going on. Also annotate QRecursiveMutex.
The tryLock code could be in principle simplified via a QScopeGuard
but I didn't want to make a central class like QMutex depend on it.
[ChangeLog][QtCore][QMutex] QMutex now has annotations for
ThreadSanitizer.
Change-Id: Ibb130404e63a5ec9bcef9675f9addd16a2c38b7f
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no reason to allow relock() on a locked locker, or unlock()
or an unlocked one, just like we don't allow that on a plain mutex
to begin with. The docs already said that e.g. relock() locks an
_unlocked_ locker.
[ChangeLog][QtCore][QMutexLocker] QMutexLocker allowed relock() and
unlock() on an already closed (resp. open) locker object. These
semantics have always been undocumented and are now unsupported
(in both cases they yield undefined behavior.)
Change-Id: Id5f67beb5dc30d6435dae88a3085fba93ec7d96e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The class is similar to unique_lock in that it allows for unlocking
and relocking. Since the locked state is tracked by QMutexLocker itself,
it's trivial to make it movable.
[ChangeLog][QtCore][QMutexLocker] The class is now movable.
Change-Id: I534044f8024575e996c12efb2236761d493798a3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Rename isLocked in preparation for a future commit. Rename m
as well for consistency.
Change-Id: I1c8d040bca6825a698ec804ea142d208abacd5cc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The idea is to prevent silly mistakes such as
QMutexLocker(mutex);
doSomething();
where the locker is constructed and destroyed immediately. Compilers
don't normally warn in these cases (as the constructor/destructor
pairs involved do have side effects), but we can mark the type as
[[nodiscard]] to encourage warnings.
There is another couple of classes for which this would make sense
(notably, the R/W lockers), but unfortunately those are exported
classes, and GCC has a bug where one can't mix two different attribute
syntaxes on the same entity [1], so I'm skipping those.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102399
Change-Id: I75a2443dc71e6b80613b8edd52a04d3379355728
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Revert a part of d3638e18d396f1935804908da717ca5cb97f2eda because the
change was not needed
Task-number: QTBUG-94407
Pick-to: 6.2
Change-Id: I7cf0969d6ecc4078d38b4241ffe7d24273a6d412
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Avoid creating a a d pointer for recursive mutexes.
Change-Id: I28af15a416ee17de346e2ea5b1442279d9d3e159
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These classes should not inherit from each other
anymore in Qt 6. The reason is that this makes
the 95% case of using a non-recursive mutex
much slower than it has to be.
This way, QMutex can now inline the fast path
and be pretty much as fast as QBasicMutex is
in Qt 5. They actually use the same code paths
now. The main difference is that QMutex allows
calling tryLock() with a timeout, which that
is not allowed for QBasicMutex.
[ChangeLog][QtCore][QMutex] QMutex does not support
recursive locking anymore. Use QRecursiveMutex for that
purpose. QRecursiveMutex does not inherit QMutex anymore
in Qt 6.
Change-Id: I10f9bab6269a9181a2e9f534fb72ce65bc76d989
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since we're going to split QMutex and QRecursiveMutex into
separate classes, make sure QMutexLocker is prepared for that.
Change-Id: Id5e9a955d1db7c8ee663dd3811ad6448dad0aeae
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
As directed by ### Qt 6 comment.
Task-number: QTBUG-85700
Change-Id: Iae4179b017840efe4902de2b1529cf7ec0606865
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Both normal and relaxed constexpr are required by our new minimum of
C++17.
Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744
Reviewed-by: Sona Kurazyan <sona.kurazyan@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>
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>
In preparation of Qt6 move away from pre-C++11 macros.
Change-Id: I44126693c20c18eca5620caab4f7e746218e0ce3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add it to configure.json and replace all occurrences of QT_NO_THREAD
with QT_CONFIG(thread). Add conditions for other features that depend
on thread support. Remove conditions where we can use the QMutex and
QThreadStorage stubs.
Change-Id: I284e5d794fda9a4c6f4a1ab29e55aa686272a0eb
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
clang required adding template clauses to a few \fn commands.
|| defined(Q_CLANG_QDOC) was also added in qmutex.h.
Change-Id: I7e61f460a8f8f15032094fb35c02f73721a5eb8a
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Commit 02dc39fa8ee6fd9945728e12208a9e313ac4dd4b added the constructor
for the bootstrapped mode. For the regular mode, we hadn't needed, since
the {} syntax guaranteed initialization for us.
Turns out there's at least one compiler that doesn't think it was enough
(GCC for QNX 7).
Task-number: QTBUG-64451
Change-Id: Ic632b4163d784b83951cfffd14f6766b4cb4eb64
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Liang Qi <liang.qi@qt.io>
QBasicMutex and QMutex are the same in bootstrap mode.
Change-Id: Icaa86fc7b54d4b368c0efffd14eed63343ddb51b
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
qmutex.h is updated to let clangqdoc document the threads case,
because the no-threads case is not interesting, and clang can
handle everything declared in qmutex.h. This change required
that a few minor qdoc errors be corrected in qmutex.cpp as well.
Change-Id: Icb4122f2179d6aad39dc68376498364820143297
Reviewed-by: Martin Smith <martin.smith@qt.io>
By templating on the <chrono> types and unconditionally using
duration_cast to coerce the duration into a milliseconds, we
allowed code such as
mutex.try_lock_for(10us)
to compile, which is misleading, since it's actually a zero-
timeout try_lock().
Feedback from the std-discussions mailing list is that the
wait_for functions should wait for _at least_ the duration
given, because that is the natural direction of variance
(tasks becoming ready to run might not get a CPU immediately,
causing delays), while an interface that documents to wait
_no more_ than the given duration is promising something it
cannot fulfill.
Fix by converting the given duration to the smallest number
of milliseconds not less than the original duration. If that
is not representable in an int, use INT_MAX, emulating the
effect of a spurious wakeup, which are allowed to happen if
the function returns false in that case.
In the above example, the try_lock_for call is now equivalent
to
mutex.tryLock(1);
The tryLock() docs state that the actual waiting time does
not exceed the given milliseconds, but fixing that is a
separate issue.
Change-Id: Id4cbbea0ecc6fd2f94bb5aef28a1658be3728e52
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Section 30.4.1.3 [thread.timedmutex.requirements] has 16 paragraphs and
2 subsections.
Change-Id: I9093948278414644a416fffd1473fec7fdd2716c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Now QBasicMutex is Lockable and QMutex is TimedLockable, which means they can
be used in std::lock_guard, std::unique_lock, std::lock, etc.
[ChangeLog][QtCore][QMutex] QMutex now fully models the TimedLockable
concept by providing the try_lock, try_lock_for and try_lock_until
functions, therefore making it usable in Standard Library lock
management classes and functions.
Change-Id: I7c691481a5781a696701e1ab78186b5cefbd6a87
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
