summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread/qmutex.h
Commit message (Collapse)AuthorAgeFilesLines
* QMutex: mark the uncontended paths as Q_LIKELYThiago Macieira2025-08-141-2/+2
| | | | | Change-Id: I72ae8d8975c26d1f2e81fffd5839a2500f5edcb6 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Mark all files in corelib/thread security significantMatthias Rauter2025-08-041-0/+1
| | | | | | | | | | | | | | | None of the files in this folder handle untrusted inputs, implement a protocol or cryptographic logic or execute external code. While bugs in threading, atomics, and locks might lead to security issues, there is no elevated risk and exposure of these classes and methods. Therefore they are marked significant. Pick-to: 6.10 6.9 6.8 Fixes: QTBUG-135196 Change-Id: If336b6f8a920b3d41b4c4e57f1bff36e2b392739 Reviewed-by: Dimitrios Apostolou <jimis@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Q*Mutex: unexport for Qt 7Thiago Macieira2025-06-121-3/+11
| | | | | | | | 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>
* QBasicMutex: bring back fastTryUnlock for MSVCThiago Macieira2025-06-121-0/+5
| | | | | | | | | | | | | | | | | 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>
* QMutex::unlock: replace testAndSet with fetchAndStore for futexesThiago Macieira2025-01-201-6/+12
| | | | | | | | | | | | | 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>
* QMutex: replace QT_MUTEX_LOCK_NOEXCEPT macro with constexpr traitThiago Macieira2025-01-201-20/+30
| | | | | | | | | 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>
* QMutex/FreeBSD: mark the functions as noexcept as it always has futexThiago Macieira2024-12-131-1/+1
| | | | | | | | See qfutex_freebsd_p.h. Pick-to: 6.8 6.9 Change-Id: I7e7bbb8387ae2e7b0c39fffd65c7b03e3a65a853 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QMutex: remove QMutexPrivate from the public-ish APIThiago Macieira2024-12-051-0/+3
| | | | | | | | | | | | | | 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>
* QRecursiveMutex: make tryLock(QDeadlineTimer) the default (was: int)Marc Mutz2023-08-191-2/+2
| | | | | | | | | | | | | | | | | | | | | 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>
* QMutex: add missing <chrono> includeIvan Solovev2023-07-181-0/+2
| | | | | | | | | | 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>
* QRecursiveMutex: remove QDeadlineTimer::Forever leftoverMårten Nordheim2023-07-131-6/+0
| | | | | | | | | | | | | | | 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>
* Remove all class-level [[nodiscard]] from the code-baseMarc Mutz2023-06-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QDeadlineTimer: make the ForeverConstant an enum classThiago Macieira2023-05-251-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* QSemaphore: add QDeadlineTimer APIThiago Macieira2023-05-161-30/+0
| | | | | | | | 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>
* QMutex: add QDeadlineTimer-based tryLocksThiago Macieira2023-05-111-11/+35
| | | | | | | | | | | | | | 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>
* QMutex: remove unused tst_QMutex forward declarationThiago Macieira2023-05-041-3/+0
| | | | | | | | | | 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>
* QMutex & QReadWriteLock: do a memory read before CASThiago Macieira2023-05-011-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Short live Q_NODISCARD_CTORIvan Solovev2023-04-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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>
* Replace usages of Q_CLANG_QDOC with Q_QDOCLuca Di Sera2022-10-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Update QMutex-noexceptednessMårten Nordheim2022-10-141-1/+1
| | | | | | | | | | | 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>
* Remove preprocessor conditionals for chrono includeKonrad Kujawa2022-09-161-6/+2
| | | | | | | | | __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>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | 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>
* Annotate QMutex with TSAN annotationsGiuseppe D'Angelo2022-04-111-4/+37
| | | | | | | | | | | | | | | | 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>
* QMutexLocker: strenghten the locking operationsGiuseppe D'Angelo2022-03-181-9/+6
| | | | | | | | | | | | | | | 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>
* QMutexLocker: add move semanticsGiuseppe D'Angelo2022-03-171-0/+13
| | | | | | | | | | | | 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>
* QMutexLocker: add isLocked()Giuseppe D'Angelo2022-03-151-0/+5
| | | | | | | | | It's basically for free. [ChangeLog][QtCore][QMutexLocker] Added the isLocked() function. Change-Id: Idad5fa249ba8f135dcf81c7b7596caa3a888e99c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMutexLocker: code tidiesGiuseppe D'Angelo2022-03-091-13/+15
| | | | | | | | 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>
* Plaster [[nodiscard]] on some RAII classesGiuseppe D'Angelo2021-09-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Put Q_DISABLE_COPY(QMutex) back when features.thread is unavailableTasuku Suzuki2021-07-011-0/+3
| | | | | | | | | | 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>
* Fix build without features.threadTasuku Suzuki2021-04-151-4/+1
| | | | | Change-Id: I233808be77dbf1930ebf65b6f23298414eab1da7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Inline the members for QRecursiveMutexLars Knoll2020-10-171-5/+10
| | | | | | | Avoid creating a a d pointer for recursive mutexes. Change-Id: I28af15a416ee17de346e2ea5b1442279d9d3e159 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* <chrono> should always be available with C++17Lars Knoll2020-10-171-6/+0
| | | | | Change-Id: Ia4868259bfa25e4b929a51de6de580df7277c282 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Split QMutex and QRecursiveMutexLars Knoll2020-10-171-83/+90
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Refactor QMutexLocker to be able to handle recursive mutexesLars Knoll2020-10-171-42/+29
| | | | | | | | 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>
* Deprecate QMutex in recursive modeLars Knoll2020-09-211-3/+8
| | | | | | | | | Use QRecursiveMutex instead. Pick-to: 5.15 Change-Id: I862fc2b3143deeb5c96dc8d445be5f9fa2535670 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Remove redundant non-const QMutex::isRecursive()Edward Welbourne2020-09-101-2/+0
| | | | | | | | As directed by ### Qt 6 comment. Task-number: QTBUG-85700 Change-Id: Iae4179b017840efe4902de2b1529cf7ec0606865 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Replace Qt CONSTEXPR defines with constexprAllan Sandfeld Jensen2020-08-141-1/+1
| | | | | | | | 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>
* Don't wrap feature detection macros with QT_HAS_FOO() variantsTor Arne Vestbø2019-12-101-5/+5
| | | | | | | | | | | | | | | | | Using wrappers for these macros is problematic when for example passing the -frewrite-includes flag to preprocess sources before shipping off to distcc or Icecream. It will also start producing warnings when compilers implement http://eel.is/c++draft/cpp.cond#7.sentence-2. See for example https://reviews.llvm.org/D49091 Both https://clang.llvm.org/docs/LanguageExtensions.html and the SD-6 document at https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations recommend defining '__has_foo(x) 0' as a fallback for compilers without the macros, so that's what we go for. Change-Id: I0298cd3b4a6ff6618821e34642a5ddd6728be767 Reviewed-by: Alex Richardson <arichardson.kde@gmail.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Short live QRecursiveMutex!Marc Mutz2019-07-061-1/+33
| | | | | | | | | | | | | | | 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>
* Port from QAtomic::load() to loadRelaxed()Giuseppe D'Angelo2019-06-201-1/+1
| | | | | | | | | | | | | | | 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>
* Replace Q_DECL_NOEXCEPT with noexcept in corelibAllan Sandfeld Jensen2019-04-031-27/+27
| | | | | | | In preparation of Qt6 move away from pre-C++11 macros. Change-Id: I44126693c20c18eca5620caab4f7e746218e0ce3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Modernize the "thread" featureUlf Hermann2018-08-171-3/+3
| | | | | | | | | | 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>
* doc: Correct remaining qdoc warnings in qmutex.cppMartin Smith2018-01-041-1/+1
| | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-11-231-0/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/network/access/qhttp2protocolhandler_p.h src/network/kernel/kernel.pri src/network/ssl/qsslkey_qt.cpp src/plugins/platforms/cocoa/qcocoascreen.mm src/plugins/platforms/windows/accessible/iaccessible2.cpp src/plugins/platforms/windows/accessible/iaccessible2.h src/plugins/platforms/windows/accessible/qwindowsaccessibility.cpp src/plugins/platforms/windows/accessible/qwindowsmsaaaccessible.cpp src/plugins/platforms/windows/accessible/qwindowsmsaaaccessible.h src/widgets/widgets/qmenu_p.h tests/auto/network/access/qnetworkreply/tst_qnetworkreply.cpp tests/auto/other/qaccessibility/tst_qaccessibility.cpp tests/auto/testlib/selftests/expected_cmptest.lightxml tests/auto/testlib/selftests/expected_cmptest.teamcity tests/auto/testlib/selftests/expected_cmptest.txt tests/auto/testlib/selftests/expected_cmptest.xml Done-with: Edward Welbourne <edward.welbourne@qt.io> Change-Id: I4217cc7d840cbae3e3dd28574741544469c4c6b9
| * Fix QBasicMutex default constructor not constexprThiago Macieira2017-11-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.10' into devAllan Sandfeld Jensen2017-10-241-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/plugins/platforms/windows/qwindowsmousehandler.cpp src/plugins/platforms/xcb/qxcbimage.cpp tests/auto/network/access/qnetworkreply/tst_qnetworkreply.cpp tests/manual/qtabletevent/regular_widgets/main.cpp Done-with: Friedemann Kleint<Friedemann.Kleint@qt.io> Done-with: Mårten Nordheim<marten.nordheim@qt.io> Change-Id: I5b2499513a92c590ed0756f7d2e93c35a64b7f30
| * QBasicMutex: mark the bootstrap constructor constexprThiago Macieira2017-10-191-1/+1
| | | | | | | | | | | | | | QBasicMutex and QMutex are the same in bootstrap mode. Change-Id: Icaa86fc7b54d4b368c0efffd14eed63343ddb51b Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* | Replace Q_NULLPTR with nullptr where possibleKevin Funk2017-09-191-5/+5
|/ | | | | | | | | | | | | 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>
* doc: clangqdoc documents the threads caseMartin Smith2017-01-061-4/+8
| | | | | | | | | | 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>
* QMutex: make sure we try_lock_for no shorter than the duration passedMarc Mutz2016-11-221-8/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-11 23:57:50 +0000