This memory allocation was introduced in
314c83c0c2. With a compiler without thread
safe statics support mutex.cpp use a function named freelist() to create
the global QFreeList object. it will be created when the first time it was
accessed, but will never be released. This patch use Q_DESTRUCTOR_FUNCTION
to delete this object.
Task-number: QTBUG-48359
Change-Id: I4e4716930930aa98630101a1f96de6a7672af9cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since Q_GLOBAL_STATIC might use QMutex and cause a stack overflow.
Task-number: QTBUG-47554
Change-Id: I4853c5e9b9168d4a417200e2a45a1bf9cb103a30
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Pierre Rossi <pierre.rossi@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
qdoc only see a fake QMutex class (the same as the one built in bootstrap)
But that fake QMutex had static member while the normal QMutex class
has non static member.
QMutexLocker::mutex is also a const function in the real QMutexLocker
Task-number: QTBUG-38522
Change-Id: I220434ffc6a9e990029f770e2536ecb55b4e2182
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
This allows us to get the current value of the QMutex / QBasicMutex
after the testAndSet operation failed. It saves an extra load from
memory.
Change-Id: I4922a8b3df15e342b177b13f56cf4f1184314520
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Default values should have mark-up to denote that they are code.
This commit changes:
-"property is true" to "property is \c true".
-"Returns true" to "Returns \c true".
-"property is false" to "property is \c false".
-"returns true" to "returns \c true".
-"returns false" to "returns \c false".
src/3rdparty and non-documentation instances were ignored.
Task-number: QTBUG-33360
Change-Id: Ie87eaa57af947caa1230602b61c5c46292a4cf4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
The read from 'owner' for comparison with 'self' in QRecursiveMutexPrivate::lock()
is not synchronized with the write to 'owner' in the same function further down,
and neither operation is atomic.
Fix by making 'owner' an atomic pointer.
Change-Id: I186b88575589da0dce5827a1e17ceb4ce599ed02
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
It is deprecated and clang is starting to warn about it.
Patch mostly generated by clang itself, with some careful grep
and sed for the platform-specific parts.
Change-Id: I8058e6db0f1b41b33a9e8f17a712739159982450
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As described in the QTBUG-30872, there may be a race condition involving
3 threads fighting for a mutex. I am surprised it was not caught
before despite all the Q_ASSERT and the stress test in tst_qmutex.
We do not need to call store(0) because the unlocking thread will
eventually remove the BigNumber flag. And perhaps it even did it
already, and another thread has incremented waiters (hence the Q_ASSERT
is wrong)
Here is a paste of part of the description from the bug report:
---
many threads, one of them is ready to release mutex, while at least two other trying to acquire it
d->waiters is 0
Thread 1 release mutex in unlockInternal:
if (d->waiters.fetchAndAddRelease(-QMutexPrivate::BigNumber) == 0)
d->waiters is now -QMutexPrivate::BigNumber
Thread 2 try to acquire mutex in lockInternal:
old_waiters = d->waiters.load();
if (old_waiters == -QMutexPrivate::BigNumber) {
if (d_ptr.testAndSetAcquire(d, dummyLocked())) {
It acquire 'about to release mutex' by changing d to dummyLocked
Thread 1 continue release procedure:
d->derefWaiters(0);
d->waiters is now back to 0
Thread 3 try to acquire mutex in lockInternal:
while (!d->waiters.testAndSetRelaxed(old_waiters, old_waiters + 1));
d->waiters is now 1
Thread 2 continue its dummy lock:
d->waiters.store(0);
d->waiters is force to 0
Thread 3 continue wait procedure
but it realize that mutex was already unlocked so decrease back waiters
if (d != d_ptr.loadAcquire()) {
if (old_waiters != QMutexPrivate::BigNumber) {
d->waiters.deref();
d->waiters became negative value of -1
Neither thread need internal data so it is released back to pool
The waiters counter in released internal structure is still -1
---
Change-Id: I1b22555db764482775db6e64a8c9ffa9e1ab0cf6
Task-number: QTBUG-30872
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Documentation has been updated, changes apply to Qt5 as well as Qt4.
Change-Id: I562914a439d8d27dc9e6b1aa117007edce214cc6
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Disassembly of the optimised code shows that the compiler was already
inlining the bodies of one or both functions (since they're in the same
.cpp, it's allowed to do that).
However, since there was no "inline" marker, the compiler was also
emitting an out-of-line copy, which wasn't used by anyone, as the class
is not exported.
So add the marker. To make sure that they don't get used by accident
elsewhere, the class is moved to the .cpp file too.
Change-Id: Iead578ec9c7d8dd6b4e6bb582ce5b829cdec5992
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Non-timed mutex locks are by far more common, so let's try not to
penalise the locking of those with code that won't get used that
often.
Change-Id: I37f56d6429836467fdec2e588c0fb22d914b5d75
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Dispatch to the recursive mutex functions from QMutex::lock, tryLock
and unlock.
This has the benefit that those using QBasicMutex will not go through
the testing for recursive mutexes. It simplifies a little the code for
those users.
For the users of QMutex, the code required to perform a lock does not
appear to change.
Change-Id: I0ca9965e012b283c30f1fab8e9f6d9b3288c2247
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
A non-recursive mutex doesn't suddenly become recursive, so we don't
need to check it multiple times.
Change-Id: Id040254b6142d320a7bd3111491082ad09968404
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
A recursive mutex operates on top of a non-recursive mutex. Therefore,
we can bypass the test for recursive.
The end result is simply that the compiler can inline the locking and
unlocking a little better inside the lock() and unlock() functions
Change-Id: Ic06d1344ccd411c22cbdef74536f3a4d368d75d7
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Unlocking a mutex can never throw an exception. That doesn't make
sense and our code should make sure it can't happen. Right now,
provided that the system-level functions don't throw, we don't either.
Locking a mutex cannot throw on Linux because we use futexes
directly. A non-recursive mutex is just a futex, whereas a recursive
mutex uses a mutex (a futex) to manage a lock count.
However, on other platforms, due to the freelist, there can be memory
allocation, which means it might throw std::bad_alloc. Not because of
the freelist itself (that uses malloc and will just crash if malloc
fails) but because of Q_GLOBAL_STATIC. In 5.1, the global static will
be noexcept provided the type's constructor is so too (it is, in this
case).
Change-Id: I4c562383f48de1be7827b9afb512d73eaf0792d5
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I19d3b2e9a5180b13deb828b55195404ef20be295
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
See the discussion of this topic on the mailing list:
http://lists.qt-project.org/pipermail/development/2012-May/003943.html
The consensus is to not have these methods have inline code to actually
acquire the lock (i.e. no atomic test-and-set or similar). QBasicMutex
is unchanged, and continues to have inlined lock(), tryLock(), and
unlock(). QMutexLocker has been changed to always call QMutex::lock()
(even though the constructor takes a QBasicMutex parameter).
Change-Id: Ic7d2d9d581e6b254c84fdfdd8ce6c425535a8078
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This change fixes most qdoc errors in QtCore. There are about 900 left.
The main thing this change does is moving documentation from qtcore from
/doc/src to /src/corelib/doc.
Other issues resolved are mis-use of qdoc commands.
Change-Id: I002d01edfb13575e8bf27ce91596a577a92562d1
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@nokia.com>
LSB doesn't allow syscalls, so fall back to the normal _unix
implementation
Change-Id: I8aba6147da8b46e3f85b0454cf9aca219811c9fe
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
... since the latter is now deprecated and will be removed.
Change-Id: I456c1bf93ebf119c028bc4a63f1f8a31f069b83b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
QMutexPrivate takes more memory than necessary, and also initialize
platform specific ressources.
Change-Id: I70be1b89b1c21499645785ae47693a6b2514e28b
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Because we use d as a local variable.
We used this->d to refer it, but this can be confusing to have twice the same
name
Change-Id: I570aa5f444ada358eb456d6b3d9b8bfa60b10bbf
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Change Ie3271abd1728af599f9ab17c6f4868e475f17bb6 didn't build on Mac in
debug mode. This commit fixes the build.
Change-Id: I925af83ea577228b60679af804aa7875a779ec3f
Reviewed-on: http://codereview.qt-project.org/6331
Sanity-Review: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Most of these changes are search-and-replace of d->ref ==, d->ref !=
and d->ref =.
The QBasicAtomicPointer in QObjectPrivate::Connection didn't need to
be basic, so I made it QAtomicPointer.
Change-Id: Ie3271abd1728af599f9ab17c6f4868e475f17bb6
Reviewed-on: http://codereview.qt-project.org/5030
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
And added a POD QBasicMutex. (QBasicMutex* can safely be
static_cast'ed to QMutex*)
The d pointer is not anymore always a QMutexPrivate.
If d == 0x0: the mutex is unlocked
If d == 0x1: the mutex is locked, uncontended
On linux:
if d == 0x3: the mutex is locked contended, waiting on a futex
If d is a pointer, it is a recursive mutex.
On non-linux platforms:
When a thread tries to lock a mutex for which d == 0x1, it will try to
assing it a QMutexPrivated (allocated from a freelist) in order to wait
for it.
Change-Id: Ie1431cd9402a576fdd9a693cfd747166eebf5622
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-on: http://codereview.qt.nokia.com/2116
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Olivier Goffart <olivier.goffart@nokia.com>
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
Olivier Goffart
jian liang
Jani Heikkinen
Matti Paaso
Thiago Macieira
Jerome Pasion
Marc Mutz
Stephen Kelly
Sergio Ahumada
Michele Caini
Iikka Eklund
Sergio Ahumada
Bradley T. Hughes
Casper van Donderen
Harald Fernengel
Jason McDonald
Olivier Goffart
Thiago Macieira
Olivier Goffart
Jyri Tahtela
Qt by Nokia