Threads and QThread

Platform-independent threads are a rarity in C++ open-source libraries, because threads are handled in different ways by different operating systems. On the other hand, it is not possible to write GUI applications without threads, since a user click may take just an instant, while the work that needs to be done in response may take much longer. Users are accustomed to being able to continue moving and clicking while their work is being done, and seeing constant progress feedback at the same time.

A single process can simulate multitasking by supporting multiple threads. Each thread has its own call stack and a current statement to execute. A multithreaded process iterates through the threads, switching to each thread's stack, executing some statements for awhile, and then switching to the next thread. Qt's thread model permits the prioritizing and control of threads.

12.2.1. QPixmap and QThread Animation Example: Movie Player

In this section we write a multithreaded animation viewer application. This application loops through a sequence of eight images on the screen. The user controls the time interval between images to speed up or slow down the process. Figure 12.4 shows the two main classes for this application.

Figure 12.4. UML diagram for Movie and MovieView

We will start with the top-level code in Example 12.13 and then drill down to the lower layers of code.

Example 12.13. src/threads/animate/moviethreadmain.cpp

The interface for starting a thread is similar to that of starting a processin both cases, start() returns immediately. Instead of running another program, the newly created thread runs in the same process, shares the same memory, and starts by calling the run() function.

The MovieThread does not actually display anythingit is a model that stores the data representing the movie. Periodically, it emits a signal containing a pointer to the correct pixmap to display as seen in Example 12.14.

Example 12.14. src/threads/animate/moviethread.cpp

In Example 12.15 we can see the slot that actually displays the images and the slot that responds to the slider signals. These slots are in the view class, as they should be.

Example 12.15. src/threads/animate/movieview.cpp

To summarize: the run() function emits a signal from the (model) MovieThread object, which will be received by a slot in the (view) MovieView object, as arranged by the connect() statement in the main() function (shown in Example 12.13). Signals are ideal for transmitting data to objects across threads. In Example 12.16 we see how the view is created, and how the slider controls the speed of the animation.

Example 12.16. src/threads/animate/movieview.cpp

The user controls the time interval between image exposures with a QSlider widget that is placed in a dock widget.

In Example 12.17, to avoid a crash on exit, we introduced a delay that makes sure the thread has enough time to be properly terminated.

Example 12.17. src/threads/animate/moviethread.cpp

Putting it all together, we have produced a movie of a spinning yin-yang symbol, using resources, signals, slots, and threads, with an interface that gives the user control of the spin speed via a docked slider widget. The following figure is a screenshot of the running program.

To load images from disk, we use the Qt resource feature (discussed in Section 11.4), which permits us to "embed" binary files into the executable.

Example 12.18. src/threads/animate/moviethread.cpp

12.2.2. Movie Player with QTimer

The MovieThread object, discussed in Section 12.2.1, simply emitted a signal periodically, with the interval determined by the user. This is a very simple use of a thread.

The QTimer class is well suited for emitting periodic signals to drive animations and other rapid but brief operations.[5] In Example 12.19 we derive our movie model class from QTimer instead of deriving it from QThread.

[5] Connecting a QTimer signal to a slot that takes a relatively long time to execute may slow down the main thread and cause the QTimer to miss clock ticks.

Example 12.19. src/threads/animate/movietimer.h

The MovieTimer class can be used in place of the MovieThread class of the previous example. We need to change only one line of the client code from Example 12.13, as we show in Example 12.20.

Example 12.20. src/threads/animate/movietimermain.cpp

In fact, the implementation of MovieTimer is simpler than that of MovieThread, as shown in Example 12.21.

Example 12.21. src/threads/animate/movietimer.cpp

QTimer is very convenient and can be used in some situations where, at first, you might think of using a QThread. A QTimer with a timeout of 0 will emit its signal as fast as possible, but only when the Qt event queue is empty. By rewriting a "worker thread" to operate in small chunks when its slot is repeatedly called, you can achieve something similar to multithreading without slowing down the user interface response.

12.2.3. Multiple Threads, Queues, and Loggers Example: Giant

In this section, we present an example of a consumer-producer problem inspired by the famous fable, "Jack and the Beanstalk." As we see in Figure 12.5, the main window of the application shows a split-screen view (provided by the QSplitter) of two text areas.

Figure 12.5. Giant versus Jack main window

The slider docked on the left determines the rate at which Jack steals the items on his list from the Giant. That rate has a random component. The LineEdit docked on the bottom allows the user to give Jack things to say to the Giant. Each text area is a LogWindow that monitors a named Logger. Both classes are provided in libutils and are documented in our API Docs.[6]

[6] We discussed how to obtain and install libutils in Section 7.4.

A Logger is an abstraction for a named stream of bytes. A Logger gets attached to a LogWindow through signals and slots.

Loggers are important tools for debugging (and, sometimes, even visualizing) multitasking processes. These are based on the Java loggers, but take advantage of Qt's signals and slots, which can send messages and objects across threads. The UML diagram in Figure 12.6 shows how these classes are related.

Figure 12.6. Loggers

When this program executes, two threads are running, Jack and Giant. Each thread emits signals and writes to loggers independently. The sequence diagram in Figure 12.7 shows how this works in one thread.

Figure 12.7. Speaking with signals

Jack and Giant have no knowledge of each otherthey are strictly decoupled. They do not include each other's header files, and they are connected to each other exclusively by signals and slots in controller code from GiantWindow. These relationships are depicted in the UML diagram in Figure 12.8.

Figure 12.8. Jack and Giant UML

Each thread has an incoming message queue (fifo). Messages may arrive in the Giant's queue faster than he can handle them. Some messages will be responded to, some will be ignored.

To make things more interesting, we have connected Jack's Logger's data signal to the Giant's hear slot, so the Giant is somewhat aware of what Jack is doing and can react to it. We show the class definition for Giant in Example 12.22.

Example 12.22. src/threads/giant/giant.h

Even without threads, both Jack and Giant have slots and receive signals emitted from the Qt event loop, as we see in Example 12.23.

Example 12.23. src/threads/giant/giant.cpp

In addition to responding to signals from the main thread, Jack and Giant each override the run() function. Example 12.24 shows the Giant's thread code, which is a typical "infinite" loop, reading input when there is some and sleeping when there is not.

To simulate the Giant's difficulty hearing the sounds made by a creature as tiny as Jack, we use the distort() function to introduce some noise into his process() function.

Example 12.24. src/threads/giant/giant.cpp

GiantWindow is a very primitive GUI front end for Giant. It has slots that can be hooked up to the giant's signals, as we see in Example 12.25.

Example 12.25. src/threads/giant/giantwindow.h

The constructor spells out the details of arranging things on the screen and connecting signals with slots. Example 12.26 shows some of those details.

Example 12.26. src/threads/giant/giantwindow.cpp

12.2.4. Thread Safety and QObjects

A QObject that was created in a particular thread "belongs" to that thread and its children must also belong to the same thread. Having parent-child relationships that cross over threads is forbidden by Qt.

A thread-safe object is one that can be accessed concurrently by multiple threads and is guaranteed to always be in a "valid" state. QObjects are not "thread safe" by default. To make an object thread safe, there are a number of approaches to take. Some are listed here, but we recommend the Qt 4 Thread Support[7] documentation for further details.

[7] http://oop.mcs.suffolk.edu/qtdocs/threads.html

1. QMutex, for mutual exclusion, along with QMutexLocker, allows an individual thread T to protect (lock) an object or a section of code so that no other thread can access it until T releases (unlocks) it.
2. QWaitCondition, combined with QMutex, can be used to put a thread into a non-busy block state where it can wait for another thread to wake it up.
3. A QSemaphore is a more generalized QMutex for situations where a thread may need to lock more than one resource before doing its work. Semaphores make it possible to ensure that a thread only locks resources when enough are available for it to do its job.

Exercise: Threads and QThread