Мы используем мьютекс для контроля любого доступа к переменной usedSpace. Функция QWaitCondition::wait() может принимать в первом своем аргументе заблокированный мьютекс, который она открывает перед блокировкой текущего потока и затем вновь блокирует его перед выходом.
В этом примере мы могли бы заменить цикл while
while (usedSpace == BufferSize)
bufferIsNotFull.wait(&mutex);
на инструкцию if:
if (usedSpace == BufferSize) {
mutex.unlock();
bufferIsNotFull.wait();
mutex.lock();
}
Однако это не будет правильно работать, как только мы станем использовать несколько потоков, формирующих данные, поскольку другой такой поток может захватить мьютекс сразу же после вызова функции wait() и вновь отменить условие «буфер не заполнен».
01 void Consumer::run()
02 {
03 for (int i = 0; i < DataSize; ++i) {
04 mutex.lock();
05 while (usedSpace == 0)
06 bufferIsNotEmpty.wait(&mutex);
07 cerr << buffer[i % BufferSize];
08 --usedSpace;
09 bufferIsNotFull.wakeAll();
10 mutex.unlock();
11 }
12 cerr << endl;
13 }
Поток—приемник работает в точности наоборот относительно первого потока: он ожидает возникновения условия «буфер не пустой» и возобновляет работу любого потока, ожидающего условия «буфер не заполнен».
Во всех приводимых до сих пор примерах наши потоки имеют доступ к одинаковым глобальным переменным. Но для некоторых многопоточных приложений требуется хранить в глобальных переменных неодинаковые данные для разных потоков. Эти переменные часто называют локальной памятью потока (thread-local storage — TLS) или специальными данными потока (thread-specific data — TSD). Мы можем «схитрить» и использовать отображение, в качестве ключей которого применяются идентификаторы потоков (возвращаемые функцией QThread::currentThread()), но более привлекательное решение состоит в использовании класса QThreadStorage<T>.
Обычно класс QThreadStorage<T> используется для кэш—памяти. Имея отдельный кэш для каждого потока, мы избегаем затрат, связанных с блокировкой, разблокировкой и возможным ожиданием освобождения мьютекса. Например:
01 QThreadStorage<QHash<int, double> *> cache;
02 void insertIntoCache(int id, double value)
03 {
04 if (!cache.hasLocalData())
05 cache.setLocalData(new QHash<int, double>);
06 cache.localData()->insert(id, value);
07 }
08 void removeFromCache(int id)
09 {
10 if (cache.hasLocalData())
11 cache.localData()->remove(id);
12 }
Переменная cache содержит указатель на используемое потоком отображение QHash<int, double>. (Из-за проблем с некоторыми компиляторами тип объекта, задаваемый в шаблонном классе QThreadStorage<T>, должен быть указателем.) При применении первый раз кэша в потоке функция hasLocalData() возвращает false, и мы создаем объект типа QHash<int, double>.
Кроме кэширования класс QThreadStorage<T> может использоваться для глобальных переменных, отражающих состояние ошибки (подобных errno), чтобы модификации в одном потоке не влияли на другие потоки.
Взаимодействие с главным потоком
При запуске приложения Qt работает только один поток — главный. Только этот поток может создать объект QApplication или QCoreApplication и вызвать для него функцию exec(). После вызова exec() этот поток либо ожидает возникновения какого-нибудь события, либо обрабатывает какое-нибудь событие.
Главный поток может запускать новые потоки, создавая объекты подкласса QThread, как мы это делали в предыдущем разделе. Если эти новые потоки должны взаимодействовать друг с другом, они могут совместно использовать переменные под управлением мьютексов, блокировок чтения/записи, семафоров или специальных событий. Но ни один из этих методов нельзя использовать для связи с главным потоком, поскольку они будут блокировать цикл обработки событий и «заморозят» интерфейс пользователя.
Для связи вторичного потока с главным потоком необходимо использовать межпоточные соединения сигнал—слот. Обычно механизм сигналов и слотов работает синхронно, т.е. связанный с сигналом слот вызывается сразу после генерации сигнала, используя прямой вызов функции.
Однако когда вы связываете объекты, «живущие» в других потоках, механизм взаимодействия сигналов и слотов становится асинхронным. (Такое поведение можно изменить с помощью пятого параметра функции QObject::connect().) Внутри эти связи реализуются путем регистрации события. Слот затем вызывается в цикле обработки событий потока, в котором находится объект получателя. По умолчанию объект QObject существует в потоке, в котором он был создан; в любой момент можно изменить расположение объекта с помощью вызова функции QObject::moveToThread().