qatomic_sparc.h was removed previously as part of general cleanup of
old atomic code for Qt 5.3. Unfortunately SPARC include reference was
not removed resulting in build failure on that platform.
Task-number: QTBUG-41384
Change-Id: Ic6e31b32324b0e5dd3700a6a21515a8eea5668bd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Background:
It is often necessary/advisable to schedule tasks on thread pools !=
globalInstance(). As Herb Sutter writes in
http://www.drdobbs.com/parallel/use-thread-pools-correctly-keep-tasks-sh/216500409
and the Qt Training Material stresses, tasks you schedule on a (global)
thread pool should be non-blocking, which currently rules out using any of
the QtConcurrent functions for, say, file I/O.
Nonetheless it's often convenient to have thread pools also for file I/O, as
the thumbnail viewer exercise in the Qt Training Material shows. In this
case, you'd use a dedicated thead pool, leaving the global thread pool for
CPU-bound tasks.
Yet, none of the QtConcurrent functions allow to pick the QThreadPool
instance on which to schedule the work created with them.
This patch prepares for them to do so.
This is the first part of the forward-port of
https://qt.gitorious.org/qt/qt/merge_requests/1281.
Implement by using a new QThreadPool* member that defaults to nullptr,
and adding setThreadPool to set this member, then using it in lieu of
QThreadPool::globalInstance() everywhere.
I chose to leave m_pool == nullptr to mean globalInstance() to avoid
creating the global instance whenever a QFuture is created, even if the
future represents the result of a calculation not run on the global thread
pool.
[ChangeLog][QtCore][QFuture] Can now be used with any QThreadPool, not
just globalInstance().
Task-number: QTBUG-17220
Change-Id: I4e1dc18d55cf60141b2fa3d14e2d44a3e9e74858
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Saves us from an extra load in the loop when the result is already
there.
Change-Id: Ib65b5b13f27975b8fc88be9b888c19505bf5e07c
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Conflicts:
mkspecs/qnx-x86-qcc/qplatformdefs.h
src/corelib/global/qglobal.h
src/network/socket/qnativesocketengine_winrt.cpp
src/plugins/platforms/android/androidjniaccessibility.cpp
src/plugins/platforms/windows/qwindowswindow.cpp
Manually adjusted:
mkspecs/qnx-armle-v7-qcc/qplatformdefs.h
to include 9ce697f2d5
Thanks goes to Sergio for the qnx mkspecs adjustments.
Change-Id: I53b1fd6bc5bc884e5ee2c2b84975f58171a1cb8e
Don't create a dispatcher for all adopted threads, only the main thread.
This was causing the GUI thread to skip platform dispatcher creation.
Change-Id: Id0de976f9def48e8d58efd20815b6fd18faebefa
Reviewed-by: Andrew Knight <andrew.knight@digia.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>
Instead of using std::thread, use the WinRT ThreadPool to manage
threads. This allows for setting the scheduling priority, and provides
a path to enable XAML integration (which requires Qt run on a background
thread).
QThread::terminate() is still unsupported, and only the winmain thread
can be adopted due to the behavior of the thread pool when creating
tasks from the GUI thread. The associated tests are now skipped, and
all other QThread tests pass.
Task-number: QTBUG-31397
Change-Id: Ib512a328412e1dffecdc836bc39de3ccd37afa13
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
There is no guarantee that the handle from std::thread will be valid
when a wait is made. Instead, simply use an elapsed timer and check
if the thread is finished. This prevents an exception from being thrown
when a bad handle is encountered.
Task-number: QTBUG-31397
Change-Id: Ie2a7e6cbfbb27bf1baff779322670d85e92e10dd
Reviewed-by: Oliver Wolff <oliver.wolff@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>
sleep_for appears to be unreliable (resulting in infinite waits) when
used in a thread which is also using native waiting methods. This is
also a step in the direction of eliminating std::thread's usage in WinRT.
Change-Id: I58bc4bf9ada25de247849333ef925964676b7239
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Instead of looping unnecessarily on top of testAndSet.
Task-number: QTBUG-37031
Change-Id: I8120f8405eb76dccc9066749cee0a92b0f2da20e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Sergio Ahumada <sahumada@blackberry.com>
[ChangeLog][QtCore][Atomic support]Added more operations to the atomic
classes, including operator T(), operator=(T), operator++,
operator--. For the QAtomicInteger, bit-manipulation operations are
also provided, both in operator and in fetchAndXxxYyyyyy modes.
Change-Id: I39c07be74e15e0a48f9e931f4342b182004dee1a
Reviewed-by: David Faure <david.faure@kdab.com>
This is extremely useful, since the most common action after a failed
compare-and-swap is to loop around, trying again with the current
value as found in memory.
Code currently written as:
do {
Type value = atomic.load();
...
} while (!atomic.testAndSetRelaxed(value, desired));
Becomes:
Type value = atomic.load();
do {
...
} while (!atomic.testAndSetRelaxed(value, desired, value));
In most CPU architectures, the value that was found in memory is known
to the compare-and-swap code, so this is more efficient than the
previous code. In architectures where the value is not known, the new
code is no worse than before.
The implementation sometimes modified an existing function, sometimes
it added a new one, depending on whether more registers were needed in
the assembly (like ARMv6-7), the code became more complex (ARMv5), the
optimizer failed (C++11), or it was just plain equivalent (MIPS).
Change-Id: I7d6d200ea9746ec8978a0c1e1969dbc3580b9285
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Don't delete the thread object without detaching it, use detach()
instead of CloseHandle(), and avoid a double-delete.
Change-Id: Ia169a96fb32805e06abe099c3c35e97ce485f088
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
This simplifies the code a lot and avoids silly mistakes where a
specific integer type is missing (such as char16_t).
Change-Id: Id91dfd1919e783e0a9af7bfa093ca560a01b22d1
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
No need to redefine everywhere, since they're required to be supported.
Change-Id: I2bdbbd0b0c44871e3bd0edcf0289fc58dd50ff31
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
This is already implemented in qatomic_x86.h, qatomic_ia64.h,
qatomic_mips.h, qatomic_armv6.h, and qatomic_cxx11.h. For
qatomic_msvc.h, we've just fixed it.
For qatomic_gcc.h, we know that the compiler supports it, so just add
it. According to the GCC manual, it might print a warning on some
platforms, so we only enable that on 64-bit builds.
For qatomic_unix.h, the support was missing (along with support for
unsigned 32-bit), so this commits adds it.
For qatomic_armv5.h, the platform does not always support 64-bit
atomics, but ARMv5 cannot compile in 64-bit mode anyway.
Change-Id: Ia8b3b5c641f11e5df05937fe7442be0a223174ef
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
QAtomicInteger<T> is to QBasicAtomicInteger<T> what QAtomicInt was to
QBasicAtomicInt: just a little more syntactic sugar. The Basic classes
do not always have a constructor, since they depend on compiler
support. The constructor is always present in the non-Basic class, at
the expense of making it non-POD for C++98 code.
This commit also repurposes most of QAtomicInt's documentation for
QAtomicInteger. It adds only the Q_ATOMIC_INTnn_IS_SUPPORTED macro
that explains whether the given type is supported on this platform.
Change-Id: I58886d6fa49fea4de24015c40dae29c9fa534e00
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Kurt Pattyn <pattyn.kurt@gmail.com>
When building with debug, all SLOT or SIGNAL macros will
expand to a function call, and then function will call
QThreadData::current(), which will set
QCoreApplication::theMainThread if it has not already been
done. Since Qt Widgets has these macros in the static
initialization of the library, we would register the
Android main thread as the main thread of Qt, which would
mean that the actual application object was created on
a different thread than the main thread. This caused warnings
to appear, and also triggered a race condition which
caused widget applications to sometimes show a black screen
instead of content on startup when run with the OpenGL plugin.
Task-number: QTBUG-35048
Change-Id: Ie8979f5e7cd5662f8d7dd276de9f94f27cc120b5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the diff -w for this commit is empty.
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I77bb84e71c63ce75e0709e5b94bee18e3ce6ab9e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Move private classes in the .cpp file (they aren't needed outside)
- Conform to Qt style, such as includes and braces
- Use ComPtr where appropriate
- Use foreach where appropriate
- Remove non-functional wake/interrupt leftovers
- Remove redundant timer list
- Make the timer callback a static method, so it won't crash if it
gets called on shutdown
Task-number: QTBUG-35945
Change-Id: I5426fba2735e908a04ea60287f9936f5abde6644
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
The new atomic code was introduced in Qt 5.0. The platforms that did not
get ported were announced as deprecated in Qt 5.2. The code is now
removed in Qt 5.3.
The status for the platform/compiler/OS combinations affected is:
* Linux with GCC or Clang: still compiles on all platforms
(via qatomic_cxx11.h or qatomic_gcc.h)
* INTEGRITY with Green Hills compiler: no longer compiles
* Solaris on UltraSPARC, with Sun Studio: no longer compiles
* AIX on POWER5 or 6, with IBM Visual Age: no longer compiles
(probably did not compile Qt 5.0 either)
* VxWorks in kernel mode: no longer compiles
[ChangeLog][General] Support for the following platforms has been
removed, due to lack of interest in updating support: INTEGRITY,
VxWorks, Solaris on UltraSPARC (with the Sun Studio compiler suite), AIX
on POWER processors (with IBM Visual Age compiler suite).
Change-Id: I8a961385fd95011c016b2b1eec52034794dae3e1
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Before, we'd get just an error message that the size of the array was
negative. Now, for C++11 compilers, we get a better error message:
qbasicatomic.h:117:5: error: static assertion failed: Template parameter is not a supported integer on this platform
qbasicatomic.h:119:24: error: invalid use of incomplete type ‘struct QAtomicOps<long long unsigned int>’
Change-Id: I6b0792254c0dc6103a4a7608f2942d59cda07c00
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The T was missing in QT_BASIC_ATOMIC_HAS_CONSTRUCTORS. This makes
QAtomicInt's constructor become constexpr.
Change-Id: Ibe58ff36517c5d05ce8af9c0f28169fa63521632
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
The public documentation for load() and store() says it's atomic,
and it is:
* using _q_value.store(newValue, std::memory_order_relaxed) in the C++11
implementation
* using a simple assignment otherwise, which is atomic (and relaxed, no
memory barriers) on all the existing C++ ABIs.
Change-Id: I40faa47120163225bd11c3a32514ac97ef8bbbd4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The current synchronization mechanism was racy: decrementing waitingThreads
and then hoping that the wakeOne will wake a thread before its expiry
timeout happens. In other words, on timeout, a just-assigned task would
never run. And then no other task would run, if maxThreadCount is reached.
Fixed by using a queue of waiting threads (rather than just a count), and by
moving the wait condition into the thread itself, so we know precisely
which one we're waking up, and we can remove it from the set of waiting threads
before waking it up, and therefore it can determine on wakeup whether it
has work to do (caller removed it from the queue) or it expired (it's still
in the queue). This is reliable, whereas the return value from QWaitCondition::wait
isn't reliable, when the main thread has already decided that this thread
has work to do.
Task-number: QTBUG-3786
Change-Id: I1eac5d6c309daed7f483ac7a8074297bfda6ee32
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Added/Changed:
- Move content from the Thread Basics overview to the QThread class ref
- Rephrase bits for clarity
- Use more links
Removed:
- (threads-basics.qdoc) Warning against moveToThread(this): This usage
came about when people tried to add slots to a QThread subclass. This
patch adds a warning against the root cause.
- (threads-basics.qdoc) Note on sleep() et al.: They were made public in
Qt 5.0.
- (threads-basics.qdoc) The strategy for managing member variables:
Sounds error-prone. Pushing results through signals is safer.
- (qthread.cpp) The note about GUI classes: Irrelevant to QThread,
and it's already mentioned elsewhere.
Change-Id: I6bc53cc22b929523f9976d2b920f94c02bd7273e
Reviewed-by: Geir Vattekar <geir.vattekar@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
qFlagLocation() uses a global char* array to transport source location
information from the connect() side to the metaobject side. The size
of the array is 2 (two), which just about suffices for a single connect()
statement.
Obviously, if more than one thread makes a (_any_) connection at the same
time, the data is useless and, worse, there's a data race.
The non-reentrancy of qFlagLocations() cannot and need not be fixed,
but use a per-thread flagged_locations array in QThreadData so threads
don't disturb each other.
Task-number: QTBUG-3680
Change-Id: If1797c60751f551694def69afee6fbe295bbe2d2
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Rationale: a wait on a condition-variable is usually a cancellation point.
On Posix, and probably in C++ at some point, a thread cancellation is
done by (a kind of) exception unwinding the stack. To ensure that
we call reserveThread() in all cases, wrap the function pair in a RAII
class. Even if we currently don't seem to support exceptions in QtCore,
this is low-hanging fruit, and no worse than what we had before.
Change-Id: Ifb0f428ea50f9ac12be14e620615f46e00d3dd91
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.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>
- The "Concurrent Programming" page is an exact duplicate of the Qt Concurrent module landing
page.
- The "qtconcurrent intro" target is not referenced anywhere.
Change-Id: Ice9b4360783013fe972258ca54a0004be43b8766
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
To ease interruption of long running tasks, a new method
QThread::setInterruptionRequested() can be called.
The task can check QThread::isInterruptionRequested()
and act upon it by stopping itself.
These methods are designed to replace the use of a global variable
and other hacky ways to stop a task running in another thread.
Change-Id: I17622dd60d2262078210e7e4294ad6c53a6dc179
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Makes it possible for QElapsedTimer to be non-POD.
Change-Id: I5ffc59c7a93c187a4a814e6959f8383fa8d4cc44
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
QTBUG-21051 has a testcase where activeThreadCount() could actually
end up at -1 (converted to an autotest in this commit).
The reason was: start() calls tryStart() which returns false due to
too many active threads (reserveThread() causes this), so it calls
enqueueTask() - which actually wakes up the waiting thread, but
it didn't decrement the number of waiting threads.
Note that tryStart() is "if I can grab a waiting thread, enqueue task and wake it"
while start(), in case tryStart() fails, wants to "enqueue, and then if I can grab
a waiting thread, wake it". This is why enqueue shouldn't wake; waking must happen
only if we can grab a thread (d->waitingThreads > 0).
Task-number: QTBUG-21051
Change-Id: I3d98337103031c9bdf0bf365295f245be0c66aa7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Rather than trying to make it lock-free (which requires double-bookkeeping of
4 atomic ints!), just lock the mutex before calling it.
tst_bench_qthreadpool shows no difference whatsoever between the two
solutions, I get 0.005 msecs per iteration in startRunnables().
Of course looping over calls to activeThreadCount() is a bit slower,
from 0.0002 msecs per iteration to 0.00027 msecs, i.e. 35% more.
But polling activeThreadCount() from the app is a really wrong thing to
do anyway, this benchmark was just for my own curiosity about the
price of a mutex in a function that sums up 4 ints.
What matters is start() performance, which is unchanged (0.00007 msecs
is just noise compared to a 0.005 total, that's 1.4%).
Change-Id: I993444eef8bc68eff9badd581fae3626dfd1cc6d
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
QThreadPool::clear() method removes all queued QRunnable.
When a large number of long-running tasks are queud in a
QThreadPool its destruction, which calls waitForDone(), can
be quite long.
QThreadPool:clear() removes (and deletes when appropriate)
all QRunnable that have yet to be started from the queue
enabling a faster interruption.
Change-Id: Ie5d6028ad3cfe7e439d1db068c8d0936ff818db9
Reviewed-by: David Faure <david.faure@kdab.com>
Flip !Q_OS_IOS conditions to Q_OS_MACX where it seems appropriate,
remove a redundant condition in qtextcodec_p.h.
Change-Id: I21c8c0c490f1eb4a9337a7f2f3e907c125489438
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.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>
We destroy the thread data for the main thread when the QCoreApplication
is destructed, and then delete the pthread key for the thread data in
the global static destructor function 'destroy_current_thread_data_key'.
The user may have its own Q_DESTRUCTOR_FUNCTION though, which may or may
not run after we've destroyed the key. If it runs after we've destroyed
the key, we'll end up trying to re-create the tread-data, as expected,
but set_thread_data() will fail to persist it, as pthread_setspecific
is called with an invalid key. The result is an infinite recursion:
...
6 in QThreadData::current () at qthread_unix.cpp:216
7 in QObject::QObject (this=0x48e1b30, dd=@0x48e1b40, parent=0x0) at qobject.cpp:703
8 in QThread::QThread (this=0x48e1b30, dd=@0x48e1b40, parent=0x0) at qthread.cpp:396
9 in QAdoptedThread::QAdoptedThread (this=0x48e1b30, data=0x48e1af0) at qthread.cpp:120
10 in QAdoptedThread::QAdoptedThread (this=0x48e1b30, data=0x48e1af0) at qthread.cpp:130
11 in QThreadData::current () at qthread_unix.cpp:219
12 in QObject::QObject (this=0x48e1a20, dd=@0x48e1a30, parent=0x0) at qobject.cpp:703
...
To solve this, we reset current_thread_data_once when destroying the key,
so that subsequent calls to pthread_once to potentially create the key
will call create_current_thread_data_key once more. This means we'll leak
the key for this particular use-case, since we don't end up calling
pthread_key_delete a second time, but this leak is small and happens
typically only for a short duration during application shutdown.
Change-Id: I580484a3239849e891172e24e7f77b75afd2c51b
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The optimisation done in cbaf52b099 for Qt
5.0 got the order wrong of the comparison. The queue must be sorted in
decreasing priority order. But since higher numbers mean higher
priority, that means the queue must be sorted in decreasing priority
number order.
Task-number: QTBUG-29163
Change-Id: Iaf3424b9bb445bf5c71518927f37253cead454f3
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.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>
Simply say that the behaviour is undefined if you don't do what you must
do. I don't want to introduce a check: it can't be done reliably anyway.
Task-number: QTBUG-30806
Change-Id: Iba1bbbdfe62ffcb133f9c52215efdcc0ee7bd9bd
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The comments in this file suggested that the bug was only present in clang/3.1.
However, qRegisterMetaType was failing even on clang 3.2
("tags/RELEASE_32/final"). The clang's bugzilla says [1] that the problem was
fixed two days before the release of 3.2, but apparently it didn't make it to
the release branch.
[1] http://llvm.org/bugs/show_bug.cgi?id=13470
Change-Id: I37db8f6f6b22ab939110e79240d92313c1786d6a
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The Linux futex interface uses relative timeouts anyway, so this avoids
a double round-trip through clock_gettime: once in Qt code to calculate
absolute from relative and once in libc for reversing.
Glibc does not offer such a function because its pthread_cond objects
use a kernel interface that works on absolute times.
Change-Id: I8fbcd3f73d4364a16716b0eea17e8f5f9ab5cd05
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Even if the monotonic clock is available, Android's Bionic lacks the
pthread_condattr_setclock function, so we can't tell it to use the
monotonic clock.
Task-number: QTBUG-30450
Change-Id: I4f53708b1e834ff5d9462b3bf778b96c22662a04
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
The value of priority was read without the mutex locked, from within
the thread.
Had to extract a QThreadPrivate::setPriority method so that it can be called
with the mutex already locked. So if the main thread calls setPriority
while the thread is starting, it will be either be before or after the
"re-set priority" code at thread startup, but at least not in the middle of it.
Change-Id: I7a054f68623f61482c749274da66f3b2dcd8bcee
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
postEvent() accesses it with the postEventList mutex locked, but
processEvent() was checking it without any mutex locked.
Change-Id: I31bbb50f7a1c337067b8e3de16ee7cd11400b517
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
don't test for building specific tools when we actually only want to
know whether we are bootstrapping. so far, this was only redundant; with
the upcoming change of not bootstrapping unnecessarily it would be
outright broken.
Change-Id: I7600d8ebb14a4194640c50035e35a04263f2ccce
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The former applies both on Mac OS X and iOS, but 'macx' is specific to
Mac OS X.
ios.conf and macx.conf now share most of their settings in the common
mac.conf. We set the default QMAKE_MAC_SDK before loading mac.conf, so
that any overrides in the device config will apply afterwards. This
means configure's mkspec parsing will be able to read the QMAKE_MAC_SDK.
Change-Id: I0c7e26a6a0103e19b23ef152aa9e4ab461cee632
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
This avoids crashes accessing deleted memory when creating a QObject
after the last QObject had been deleted, like a qDebug() in global
destructors.
==41000== Invalid read of size 4
==41000== at 0x5F01ED5: bool QBasicAtomicOps<4>::ref<int>(int&) (qatomic_x86.h:208)
==41000== by 0x5F01309: QBasicAtomicInteger<int>::ref() (qbasicatomic.h:147)
==41000== by 0x5F24051: QThreadData::ref() (qthread.cpp:100)
==41000== by 0x614A984: QObject::QObject(QObject*) (qobject.cpp:681)
==41000== Address 0x6ee73f0 is 0 bytes inside a block of size 152 free'd
==41000== at 0x4A0736C: operator delete(void*) (vg_replace_malloc.c:480)
==41000== by 0x5F240BF: QThreadData::deref() (qthread.cpp:109)
==41000== by 0x6113F6B: QCoreApplicationData::~QCoreApplicationData() (qcoreapplication.cpp:268)
The comment right above the change in qthread.cpp looks eerily similar
to the problem I'm trying to fix. However, the actual change that
introduced the change is not in the Qt public history, so we can't
know for sure what the problem was then.
Change-Id: I0dba895b041fe6cf81e6f8939ca85035cd00aad1
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Based on the Necessitas project by Bogdan Vatra.
Contributors to the Qt5 project:
BogDan Vatra <bogdan@kde.org>
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
hjk <hjk121@nokiamail.com>
Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Paul Olav Tvete <paul.tvete@digia.com>
Robin Burchell <robin+qt@viroteck.net>
Samuel Rødal <samuel.rodal@digia.com>
Yoann Lopes <yoann.lopes@digia.com>
The full history of the Qt5 port can be found in refs/old-heads/android,
SHA-1 249ca9ca2c7d876b91b31df9434dde47f9065d0d
Change-Id: Iff1a7b2dbb707c986f2639e65e39ed8f22430120
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
QtCore has a few headers that, though public, aren't meant to be
included directly. Those are the atomic headers, the three _impl.h
headers and qt_windows.h.
QtGui includes two OpenGL headers that don't compile on their own.
Other libraries should not have headers like that (but they do,
something we need to fix eventually).
Change-Id: I55e4eb057748f47df927ee618f9409acbc189cc1
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The new QThread documentation now really discourage to reimplement
QThread. But in fact, there are many cases where it is perfectly fine.
And the example given is even a case where using worker object is wrong.
The examle even contains a leak since the thread will never stop and
will even leak.
This changes put back some sentences from before commit
d4ad9dbbf9.
The sample code has been re-writen. Notice how reimpementing run takes
less lines of code, less runtime overhead, no leaks, and also is more
complete than the previous example.
Change-Id: I6cb80826e917dd5ce442ccad2572ec692ccb25ab
Reviewed-by: Andre Somers <andre@familiesomers.nl>
Reviewed-by: Geir Vattekar <geir.vattekar@digia.com>
Reviewed-by: Debao Zhang <hello@debao.me>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QThread::idealThreadCount returns now the number of cores.
Change-Id: Idc23fc3c257165f6a63c6a7686a57a4fe76f6413
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The macro was made empty in ba3dc5f3b5
and is no longer necessary or used.
Discussed-on: http://lists.qt-project.org/pipermail/development/2013-January/009284.html
Change-Id: Id2bb2e2cabde059305d4af5f12593344ba30f001
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
Make them use the monotonic clock if that's available. On Mac, the
monotonic clock is not available -- Qt fakes monotonic support by using
the Mach timebase -- so we need to use gettimeofday.
Change-Id: Iaea0b0c0de1b4802780e2476dc3643b703db392c
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
In VxWorks set default values for scheduling priority to use
SCHED_FIFO_HIGH_PRI and SCHED_FIFO_LOW_PRI defines for other scheduling
policies than SCHED_RR or SCHED_FIFO.
Change-Id: If78b84cd9ef94d7712206e9442e96cdba727610f
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Both qdoc and Q_QDOC are used in source code, which looks not good.
Change-Id: I4f3a71670278b0758d92bfa5db086a07e1b1acfd
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
It's deprecated and it's not available on iOS anyway. The recommended
way of getting the number of processors online is via sysctl or
sysconf (both of which are just slightly below).
qthread_unix.cpp:397:13: error: 'MPProcessorsScheduled' is deprecated: first deprecated in Mac OS X 10.7 [-Werror,-Wdeprecated-declarations]
Change-Id: I4bf60985fbde155b78b840f3de3ff0a142b78b19
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The Linux futex implementation had a Q_ASSERT for positive values, but
the documentation says that negative values should be interpreted as
infinite (equal to lock()).
Test that too.
Change-Id: I2f96a502d672732781e88e49797756ca9a809121
Reviewed-by: David Faure (KDE) <faure@kde.org>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Terms fixing. Changes apply to Qt5 as well as Qt4.
Change-Id: Ibb31ab0d68c62f3feb63722dd967932c2543fa37
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qatomic.h includes qbasicatomic.h, so break the cyclic inclusion
problem.
Change-Id: If72bacbcfa36993336786f31e8980fbd43df8bdc
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
For two reasons: 1) those operators are gone and 2) the ones that remain
are atomic.
Task-number: QTBUG-28532
Task-number: QTBUG-24627
Change-Id: I1e9d1b076d923546c1ee3d45f312066590f97416
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
When QtBase is compiled with Exeptions it was incompatible
with the other modules compiled with QT_NO_EXCEPTIONS.
This resulted in a linker error with
ExceptionStore::throwPossibleExceptions, one time returning a const value
and the other time without it
Change-Id: I0e0dff61aceeec3cfde119b00ed15f3aa9f12659
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Change-Id: Ida190e8b9c1ff47a6f54a5bf68673ab50a2f1bfe
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
The timeout is in millisecond. So we just need to divide by 1000 to get
the number of seconds
Regression introduced in f587e8f4fd
Reported in the comments of QTBUG-24795
Change-Id: Id16e05e7d04d33605860926f7516d14cdefd6a36
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Following 731ba8ed08 this function is
not used anymore
Change-Id: Id908931b4b21c825bd80a4f03790630818c73c07
Reviewed-by: Christian Stromme <christian.stromme@digia.com>
This triggers a bug in clang (before version 3.2). See also the bug
report: http://llvm.org/bugs/show_bug.cgi?id=12670 .
Change-Id: I9e0bc1cc39059ffa5e062652b932bc01e453ef98
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Documentation has been updated, changes apply to Qt5 as well as Qt4.
Change-Id: I13241a3b4c16d2cb1b24f80fe26832467621923a
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
To avoid leaking when converting a QFuture<T> to a QFuture<void> we need
to have a separate ref. counter for QFuture<T>. When the last QFuture<T>
goes out of scope, we need to clean out the result data.
Task-number: QTBUG-27224
Change-Id: I965a64a11fffbb191ab979cdd030a9aafd4436c2
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
As of Qt5, this macro is defined to be empty; simply get rid of these leftovers.
Change-Id: I167ccb4c9e92ec9b5e4faeb02bf9c5ef5d982b50
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The signal is removed from the API; all references to it are removed
from documentation; the unit test that checks for its emission is
modified to listen for QThread::finished() instead.
The QThreadPrivate::terminated flag is also removed, as it served no
purpose other than to trigger the emission of QThread::terminated()
As discussed at http://lists.qt-project.org/pipermail/development/2012-October/007216.html
the signal is not guaranteed to be emitted after every termination,
rendering it useless.
Change-Id: I7b0c45d7889da0d33875545331606f2208ee56fc
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
In ResultStoreBase::addResults() it possible that the ResultItem we
create is invalid (filter-mode enabled). Since an invalid ResultItem
won't have any result data, we need to make sure that we don't allocate
any data for it.
Task-number: QTBUG-27224
Change-Id: Ic99b191db0e9dd4e29b64911f87d90a8148bb7a5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Be more explicit on from which thread the signals are emitted, and
mention that it is possible to connect finished with deleteLater
Change-Id: Ib72be94a81be383774f08d71915fa609843030e0
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.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>
Remove advice to subclass QThread; promote thinking of QThread as a
thread manager, not a thread; promote event-driven programming over time
micromanagement; warn against common pitfalls.
Result of collaboration in forum (https://qt-project.org/forums/viewthread/20691/)
and mailing list (https://qt-project.org/pipermail/development/2012-September/006738.html)
Task-number: QTBUG-16358
Change-Id: I57e3873976fad489176cbf9f7e680fd6992a8837
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
This class belongs to QThreadPool/QRunnable more than to QtConcurrent, so
move to QtCore, where QThreadPool awaits it.
Change-Id: Ibf20288a986593bf779453427c2dae8db1e1423a
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
No compatibility header needed. While this wasn't marked as private API,
it wasn't documented, either.
This is a prerequisite for moving QFuture to QtCore.
Change-Id: I8e986e6e2a22fbe5cf08d0600ec39ae9ae993e20
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Leave the old name as a deprecated typedef; adapt users.
This is a prerequisite for moving QFuture back to QtCore.
Change-Id: I81dcee2c7e6eb234c16f3f42e2415ca0da3dc4f8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is exactly the type of pointer arithmetics that GCC likes to
miscompile.
Just use offset >= size() (=subtract begin() from both sides).
Change-Id: Ifb13652d7b96bf4c06727d9c965516e95d16ab5c
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
QPostEventList is kept sorted by priority; std::upper_bound
is used to insert a QPostEvent in the right place in the list.
Turns out that MSVC2008 is a bit too picky and tries to see if the
list is actually ordered. This causes a build failure as there is
no operator< defined between two QPostEvents (in fact,
an integer -- the priority -- is passed to std::upper_bound).
Work around this issue by defining operator< between two QPostEvents.
Change-Id: Ie3562dd0cc7253e25fc988b25d566d9d9e9fe62b
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Simon Hausmann <simon.hausmann@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>
Replace them with std::upper_bound; this allows for deprecation of
qUpperBound.
Change-Id: Idef01d2228b9a70eee3d52931d7aedb5bb6ba902
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
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>
The non-futex implementation does not support timed locks in
QBasicMutex. That is only supported in QMutex (due to the
destructor).
Change-Id: I46d33a66a36e05c8a4344823537178e80a6ddd76
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
We're not checking the result anyway, so use a simpler operation.
Change-Id: I8c2db35be86660b29d81dd97ce3e269de55a37df
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The first time we're going to sleep, the timeout should be exactly the
value that was passed by the user. We don't need to calculate the time
elapsed between start() and a few lines below.
Change-Id: I99c363b6f0ecfd07ad787b79b75e61771733c2b3
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
Once we enter the inner loop, we never exit it except to return from
the lockInternal() function, so the rest is never executed again.
As a consequence of this, we won't try to fastTryLock() twice per
mutex. Therefore, for a non-recursive mutex, if lockInternal() is
entered, we'll definitely need to use futexes.
Change-Id: Ice617ed27449c1fbdc112a159a86cd0660125e13
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
If the timeout wasn't zero, it can only become zero if we return from
futex() with a non-timeout reason but subsequently expires while we're
recalculating something.
A side effect is that we try-lock a non-recursive mutex exactly
once. Before this change, we'd fastTryLock() twice even with
timeout == 0.
Change-Id: I0af09fc2a84669a683a843fcf1513203b075dfb7
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.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>
Use reinterpret_cast to convert from DWORD to pointer.
Change-Id: I17a12940850aeb0bc27080725a18eb93fee72ff7
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Even though I really think the change was the right thing to do, it seems
like Windows people don't like this change because of some Windows Data Types
specific rules.
This reverts parts of the commit 56d5c909af.
Change-Id: I2c67d9b1bab36fc63937ef386aef56d2a4472a04
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
The TRUE and FALSE macros are obsolete and should be replaced with
true and false (all lower case) respectively.
Change-Id: Iee352e8173500683e6319be0abbf5bacf29016e0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
We could mark the cold path with __attribute__((cold)) (since GCC 4.3),
but quick tests locally indicate that the compiler is smart enough to
determine that by itself.
It will inline the hot path in _q_futex, which in turn is inlined in the
lockInternal and unlockInternal functions, whereas the cold path is kept
outside.
Change-Id: I8ae7d851d4f050498bfb491ba87d3e25453a14f8
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.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>
There's a comment saying nanosleep's availability is questionable, but
the information of what systems don't have that is now lost in
time. It's quite likely that they were older, Unix systems we no
longer support anyway.
nanosleep comes from POSIX.1b-1993, which is merged into POSIX.1-2001,
so chances are that it's supported almost everywhere where Qt runs
(except for Windows anyway).
Change-Id: I4fd18f8715c43a42429000f3b3d2c3b7343f94b4
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
This requires using the same chain of conditions that QBasicAtomic*
uses in order to provide constructors, so we're using the newly-added
macro QT_BASIC_ATOMIC_HAS_CONSTRUCTORS to check.
Even though QAtomic<> is a template, we can't just use Q_DECL_CONSTEXPR
since the body of the constructors needs to change, too.
Change-Id: I462a80ed175040f7709c30d07d34036c6c5507d8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This macro is defined when the QBasicAtomic* types have constructors.
It will be used to simplify maintenance of QBasicAtomic subclasses,
as well as classes that aggregate Q(Basic)Atomics and wish to be
literal types if possible.
Change-Id: I7ab181c58a13ec2195449bbae5b3476b9017a8f2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows one to write code that depends on these values at
compile-time.
Change-Id: I7d78524ed9c70d4141360496d1d764dcbfa92e62
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These methods aren't often used, but currentThreadId() gets used in the
recursive mutex code to store the identity of the thread with multiple
locks.
Change-Id: I031cf3893aa6e7fd7a53733fc1088d295bdb9079
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code under mutex protection already implicitly handles the case where
queue.empty(), so just removing the pre-lock check suffices.
Change-Id: I01467aff62e61bb4efd16359dd64546ff51c6bad
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The resulting code is easier to understand, too.
Change-Id: I3cd84d85b3186860dd3ccd67c3771b82695e7f83
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Commit 3ef51efbe7 broke compilation of
qthread_unix.cpp on QNX. This fixes it by passing in the threadId to
setCurrentThreadName().
Change-Id: I24f32d8054baedbd9a65b6a80fb1f6f37e07092d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QString::toLocal8Bit() will need to call QTextCodec::codecForLocale(),
which isn't the cheapest of the functions, at least the first time it's
run. So avoid calling it when in most scenarios, the name of the QObject
isn't set, and the information is purely for debugging.
Additionally, avoid allocating memory when setting the thread name to
the class name. The class name coming from the meta object is a static
constant string and we can use it directly.
Change-Id: Ief643bad87a51487b1d41c0a2f323e80bb53e8a7
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Simon Hausmann <simon.hausmann@nokia.com>
Fix some foward references from QtCore in addition. This
will require more work.
Change-Id: Ib1bade18c2cc220a7afe25e9fca6a3f50cb1174b
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
The qdoc manual currently claims that the command must stand on its own line.
The change follows the consistency with the rest and how the example looks like
inside the qdoc manual for this command.
Change-Id: I6b653dc95cf9d84e4adf32220dace5d313678419
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
In particular, qEmergencyOut() is now completely exception-free.
Incidentally, this patch shows that Qt isn't consistent in how it
treats empty environment variables used as flags, but that is something
for a separate commit. This patch aims to be behaviour-preserving,
except in exceptional circumstances, of course.
Change-Id: Ie106e7b430e1ab086c40c81cc1e56cd0e5400cb4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Actually, only the "new" atomics are marked. The old implementation,
based on qoldbasicatomic.h is unchanged, but should still work without a
problem.
The following configurations were tested and do work:
- x86 64-bit
- x86 32-bit
- generic GCC
- generic C++11 std::atomic
- bootstrap
- ARMv6 and 7
- MIPS
- MSVC 2010 32-bit
- MSVC 2010 64-bit
The only two configurations untested are IA-64 and ARMv5. Except for
MSVC, all configurations were tested with GCC 4.6 (MIPS and ARM) and 4.7
(x86 and generics).
Change-Id: Iecbfeacd9d20b535453e91335165e9a221e0b47e
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
These functions are inline (on most architectures) but they contain
inline assembly which the compiler could not understand. In any case,
if it decides not to inline them, it would need to generate exception
handlers.
Change-Id: If9d50793d715c51781e76d0a539da03a6d83e255
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Moreover, exporting it causes the horrible side-effect on Windows
(with MSVC) that the compiler will not inline the functions, but
instead will place indirect calls to the functions in QtCore DLL,
even in release mode. For such a critical piece of code, inlining
is necessary.
Change-Id: Ib31c12f6bf8dc8ece1b51824716a480559753c24
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
This is so we can insert valgrind (helgrind) annotation macros. They
require the actual address of the variable to work.
Change-Id: I988f6a46385ad58143c53ad34b6cf0f58be2cdb8
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
QMutexLocker does not support being passed already-locked mutexes,
unless they are recursive mutexes. But in that case, it behaves as if
the mutex weren't locked in the first place.
Since that's the case, there's no point in testing the low bit to see if
it's set or not. It's never going to be.
Change-Id: Ie4b81f7e2cca16e6db36f3cb51a5377dbdfc157d
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
Based on reviewer comments on
https://codereview.qt-project.org/#change,25992, split
Q_COMPILER_DEFAULT_DELETE_MEMBERS into
Q_COMPILER_DEFAULT_MEMBERS and Q_COMPILER_DELETE_MEMBERS. Clang provides
2 separate feature checks for these, all other compilers always define
both.
Keep the Q_COMPILER_DEFAULT_DELETE_MEMBERS define, though, for any
existing code that may be using it.
Change-Id: I8969e10989c776a822da153152cfecb99dda8cb9
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Android does not support some parts of POSIX. It's also unfortunately not
POSIX-compliant, meaning we need to guard things like pthread_cancel.
Change-Id: I2979eb5579c822f4f5ba27bcc29e118b908e8bdc
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Even though we really shouldn't, we can get away with using __NR_futex instead.
Done-with: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I0ba449b740acf2c78825f8093d1515a74f0bc9cd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This ensures interoperability between the Blackbery C and C++ APIs
and makes it easier to expose platform services in C++ that are
exposed in BPS - since events from both APIs can be processed on
the same thread.
Change-Id: I7270adc64c26396f66d9126141500d5e58be51e7
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Giuseppe D'Angelo <dangelog@gmail.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
The timeout given in milliseconds should be converted to a timespec
struct.
To separate the seconds and nanoseconds the milliseconds are first
multiplied to represent the whole value in an int64 variable.
The calculation is done on integers, so we get an overflow if the
milliseconds are bigger then 2148.
If we cast the given value to an int64 we can avoid this problem.
Fix the used cast.
Task-number: QTBUG-24795
Change-Id: I864ae227cf7dda16a6f30aa4db74acc49e20f6eb
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.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>
Replace "contains(QT_CONFIG, coreservices)" with "!ios" in config files.
Replace "QT_NO_CORESERVICES" with "Q_OS_IOS" in source files.
Change-Id: Id3b02316b245a24ce550e0b47596d18a4a409e4f
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
the most-common case is: queue is empty or filled with tasks of
the same priority; so the runnable would be put at the end of queue.
both checks are cheap for us.
also avoid detach()'ing by using const iterators
Change-Id: Iab2255f852211f9accc8d717f778671661210ef3
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
IDEs pick up hints like this, so it makes it more clear to the user
what they need to pass in.
Change-Id: I5de272395fc98391cf43963ce4416a845726bb2c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Variables that are only used in asserts.
Change-Id: I0984b676ad9b67f5ae72266b8540e8054163918f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
It's almost exactly the same code in both files, so let's have one file
only. That means we need an #ifdef for the special case of 64-bit types
on i386.
Also take the opportunity to add a comment explaining how this works.
Change-Id: I50d274fa026806ae511b1045aa8a5c25daaa0edc
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
This is the first step in merging the i386 and x86-64
architectures. The next commit will bring i386 support into
qatomic_x86.h.
Change-Id: I24105ea70f3fc29b3fb779a70053f99117440573
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Futexes on Linux can be used across processes, for inter-process
synchronisation. The private flag tells the kernel that this futex is
not used with other processes, so it does not need to check for waiters
outside the current process.
This feature had been proposed in Merge Request 25, but was lost.
Change-Id: Ieafa8b8df0949bd9ae73709b3ec63f7709b0b2a6
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
The qt_global_mutexpool was private API deprecated long time ago.
And there is no reason to call qt_create_tls because it is called in
QThreadData::current that is called from the QObject constructor, even
before QCoreApplication::init can be called.
Change-Id: Idf3576d8591377811b727b12edc43dc898570ba4
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Naming threads is very useful for release builds.
Enabling only on Linux/Mac for now.
The Windows port is using debugger specific API for setting thread
names, so it has to remain debug mode only.
Change-Id: I179521f65f215ff038e8230f958f6aa728ea4cbe
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
QDoc now has support for Doxygen style commands for italics, bold
and list items. This change applies that change in QDoc to the
actual documentation.
Task-number: QTBUG-24578
Change-Id: I519bf9c29b14092e3ab6067612f42bf749eeedf5
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Don't register the thread handle and QThread object pointer to watch list
for adopted thread watcher thread in Windows. Otherwise the watcher thread
will never exit and can't clean up its own QThreadData and QAdoptedThread
object.
Task-number: QTBUG-23961
Change-Id: Ia84326cf3cfd978d2b003ccc1bb6861db950e899
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Fix potential race condition in data structure of adopted thread watcher
in Windows. Since QVector is not thread safe, it is not safe to read and
append data to qt_adopted_thread_handles or qt_adopted_qthread
simultaneously in qthread_win.cpp. This patch fix this race condition.
Change-Id: I2d0c7a4cdde5390d38d15c98343f0fc6ddd24aba
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@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>
IBM's POWER and the PowerPC architecture have been merged into a single
ISA, the Power ISA (see http://www.power.org). Use this unified name in
Qt.
Change-Id: Ia41492b0031d890843e43c5f7ecd1e60c65bb75b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This provides a fallback implementation on UNIX when the Q_PROCESSOR_*
and Q_CC_*/Q_COMPILER_* checks fail to find an implementation.
Note that we always compile qatomic_unix.cpp, but code is only included
when QATOMIC_UNIX_H is defined (meaning the checks above did not find an
implementation).
Change-Id: I8ce047847206003b4fa96eb3fb76b1c2ffbc2dfc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Matti Paaso
Frederik Gladhorn
Thiago Macieira
Adam Majer
Marc Mutz
Andrew Knight
Olivier Goffart
David Faure
Eskil Abrahamsen Blomfeldt
Oswald Buddenhagen
Friedemann Kleint
Fatih Aşıcı
Sze Howe Koh
Jerome Pasion
Oliver Wolff
Kamil Trzcinski
Sergio Ahumada
Tor Arne Vestbø
Corentin Jabot
Jake Petroules
Stephen Kelly
Jan Kundrát
Axel Waggershauser
Paul Olav Tvete
Florian Behrens
Pasi Petäjäjärvi
Debao Zhang
Michele Caini
David Schulz
Holger Ihrig
Mitch Curtis
Orgad Shaneh
Erik Verbruggen
Christian Strømme
Konstantin Ritt
Giuseppe D'Angelo
Iikka Eklund
Kai Koehne
Sergio Ahumada
Friedemann Kleint
Sean Harmer
Lars Knoll
Laszlo Papp
Jeremy Katz
Bradley T. Hughes
Robin Burchell
Jeff Kehres
Markus Rathgeb
Sean Harmer
Casper van Donderen
Ian Dean
Oswald Buddenhagen
Harald Fernengel
Robin Burchell
Leonard Lee
jian liang