Я понимаю, что возможно предварительно выделить QList и позволить потокам работать в разных областях этого списка, но, на мой взгляд, я считаю, что это плохой шаблон для подражания.
Когда я работаю с Qt (на самом деле я работаю с PyQt, так как я программист на python), я чувствую, что лучше всего использовать предоставленный вам механизм сигнал / слот и никогда не делю память между потоками. Каждому потоку должны быть предоставлены свои собственные данные либо непосредственно при создании, либо со временем через очередь, которая ожидает. Когда это сделано с его работой или частью работы, это может испустить сигнал с данными. У вас будет один обработчик, который соединяется со всеми вашими потоками для прослушивания данных, которые будут готовы.
Результатом этого паттерна является то, что вы не делите память и вам не нужно слишком беспокоиться о блокировках, а просто ждите, когда рабочие сообщат, что их данные готовы, и один обработчик собирает и обновляет основная модель.
При этом здесь приведено еще одно упоминание о том, что кто-то использует QList в качестве разделяемой памяти и испытывает сбои до тех пор, пока не заблокирует его: http://developer.qt.nokia.com/forums/viewthread/13049
Я думаю, что когда люди (включая меня) впервые начинают работать с потоком, немедленный импульс заключается в том, чтобы просто использовать контейнеры так, как они это делают всегда. Но как только вы начнете работу с потоками, вы сразу же увеличите сложность логики кода и количество ошибок. Синхронизация разделяемой памяти - один из способов приблизиться к ней, используя мьютексы для блокировки ресурсов перед доступом. Но я думаю, что стоит упомянуть другой способ общения.
Язык Googles Go был построен с одним из основных принципов: «Не общайтесь, разделяя память; делитесь памятью, общаясь» http://golang.org/doc/codewalk/sharemem/
Go хотел решить эту проблему по своей сути, передавая память через объекты каналов, которые напоминают сигнал / слот в Qt. Один компонент имеет эксклюзивный локальный доступ к памяти, а затем передает его другому компоненту по каналу. Это гарантирует, что у вас не будет гоночных условий. В любом случае, я подумал, что я воспользуюсь этой дополнительной ссылкой, потому что я чувствую, что она очень важна для проблем программирования потоков.