Thread Support in Qt
IntroductionQt provides thread support in the form of basic platform-independent threading classes, a thread-safe way of posting events, and a global Qt library lock that allows you to call Qt methods from different threads. This document is intended for an audience that has knowledge of, and experience with, multithreaded applications. If you are new to threading see our Recommended Reading list.
Enabling Thread SupportWhen Qt is installed on Windows, thread support is an option on some compilers. On Mac OS X and Unix, thread support is enabled by adding the -thread option when running the configure script. On Unix platforms where multithreaded programs must be linked in special ways, such as with a special libc, installation will create a separate library, libqt-mt and hence threaded programs must be linked against this library (with -lqt-mt) rather than the standard Qt library. On both platforms, you should compile with the macro QT_THREAD_SUPPORT defined (e.g. compile with -DQT_THREAD_SUPPORT). On Windows, this is usually done by an entry in qconfig.h.
The Thread ClassesThese classes are built into the Qt library when thread support is enabled:
Important Definitions When using Qt in a multithreaded program, it is important to
understand the definition of the terms reentrant and thread-safe:
Note that Qt provides both implictly and explicitly shared
classes. For more information, see the Threads and Shared Data
section.
Most C++ member functions are inherently reentrant, since they only
reference class member data. Any thread can call such a member
function on an instance, as long as no other thread is calling a
member function on the same instance. For example, given the class Number below:
The methods Number::number() and Number::setNumber() are
reentrant, since they only reference unique data. Only one thread at
a time can call member functions on each instance of Number.
However, multiple threads can call member functions on separate
instances of Number.
Thread-safe functions usually use a mutex (e.g a QMutex) to serialize
access to shared data. Because of this, thread-safe functions are
usually slower than reentrant functions, because of the extra overhead
of locking and unlocking the mutex. For example, given the class Counter below:
Since the modifications of the static instances integer are not
serialized, this class is not thread-safe. So make it threadsafe, a
mutex must be used:
In Qt, one thread is always the GUI or event thread. This is the
thread that creates a QApplication object and calls
QApplication::exec(). This is also the initial thread that calls
main() at program start. This thread is the only thread that is
allowed to perform GUI operations, including generating and receiving
events from the window system. Qt does not support creating
QApplication and running the event loop (with QApplication::exec()) in
a secondary thread. You must create the QApplication object and call
QApplication::exec() from the main() function in your program.
Threads that wish to display data in a widget cannot modify the widget
directly, so they must post an event to the widget using
QApplication::postEvent(). The event will be delivered later on by
the GUI thread.
Normally, the programmer would like to include some information in the
event sent to the widget. See the documentation for QCustomEvent for
more information on user-defined events.
The QObject class itself is reentrant. However, certain rules
apply when creating and using QObjects in a thread that is not the GUI
thread.
QApplication includes a mutex that is used to protect access to window
system functions. This mutex is locked while the event loop is
running (e.g. during event delivery) and unlocked when the eventloop
goes to sleep. Note: The Qt event loop is recursive, and the library
mutex is not unlocked when re-entering the event loop (e.g. when
executing a modal dialog with QDialog::exec()).
If another thread locks the Qt library mutex, then the event loop will
stop processing events, and the locking thread may do simple GUI
operations. Operations such as creating a QPainter and drawing a line
are examples of simple GUI operations:
Any operations that generate events must not be called by any thread
other than the GUI thread. Examples of such operations are:
Events generated by these operations will be lost on some platforms.
The Signals and Slots mechanism can be used in separate threads, as
long as the rules for QObject based classes are followed. The Signals
and Slots mechanism is synchronous: when a signal is emitted, all
slots are called immediately. The slots are executed in the thread
context that emitted the signal.
Warning: Slots that generate window system events or use window system
functions must not be connected to a signal that is emitted from
a thread that is not the GUI thread. See the Qt Library Mutex section
above for more details.
Qt provides many implicitly shared and explicitly shared classes. In
a multithreaded program, multiple instances of a shared class can
reference shared data, which is dangerous if one or more threads
attempt to modify the data. Qt provides the QDeepCopy class, which
ensures that shared classes reference unique data.
See the description of implicit sharing for more
information.
A connection can only be used from within the thread that created it.
Moving connections between threads or creating queries from a different
thread is not supported.
In addition, the third party libraries used by the QSqlDrivers can impose
further restrictions on using the SQL Module in a multithreaded program.
Consult the manual of your database client for more information.
Some things to watch out for when programming with threads:
|
Publicité
Best OfActualités les plus luesSemaine
Mois
Année
Le Qt Developer Network au hasardApplications mobiles modernes avec Qt et QMLLe Qt Developer Network est un réseau de développeurs Qt anglophone, où ils peuvent partager leur expérience sur le framework. Lire l'article.
CommunautéRessources
Liens utilesContact
Qt dans le magazine |
Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. | Qt 3.3 | |
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD. | ||
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP ! |
Copyright © 2000-2012 - www.developpez.com