Самое оно для дебаг-билдов. И проверять на правильный поток в методах, и добавлять другие проверки...
Больше всего радует когда пишут для дебагера, ну так сразу чтоб уйти в глубокую отладку своего говнокода :D ЗЫ на своих проектах пользовал профайлеры, полезная штука. А вот дебагер как-то не пригождался, даже освоить никак не выходит без реальной практики, только теория. Если ошибка не в ДНК (того кто реализовывал и/или проектировал) её легко найти внимательным осмотром кода.
С сигнал-слотами проблемы не ловятся такими проверками. Стандартный баг в этом случае состоит в том, что тред 1 посылает сигнал о событии треду 2, при этом обработка в треде 2 требует доступа к общим данным. Пока сообщение еще не пришло, тред 1 может получить событие, по которому данные изменятся и тред 2 будет удивлен. Вот то, что мне приходится фиксить том легаси проекте, стандартная проблема обработки асинхронных событий.
С сигнал-слотами проблемы не ловятся такими проверками. Стандартный баг в этом случае состоит в том, что тред 1 посылает сигнал о событии треду 2, при этом обработка в треде 2 требует доступа к общим данным. Пока сообщение еще не пришло, тред 1 может получить событие, по которому данные изменятся и тред 2 будет удивлен. Вот то, что мне приходится фиксить том легаси проекте, стандартная проблема обработки асинхронных событий.
Проблема дизайна (не сигнал-слота, а проекта), как я и говорил нужно понимать что ты делаешь. И тут виноват не инструмент. Сигнал-слот очень хороший и удобный инструмент для обмена между потоками, если им правильно пользоваться. Но любой хороший инструмент имеет остроту, резать топором тунца на суши не удобно, да. А скальпелем дрова колоть как-то не айс.
всё там так, юзал. другое дело, что Qt не может в GUI в разных потоках. при этом, возможности Qt GUI не ограничиваются. ах, ну и в кутях не любят исключения, из-за проблем с мутексами. хотя, это традиционная беда.
Внутри какого мютекса? обертки мютексов по-идее никогда не кидают исключений сами. А если ты имеешь в виду в области, закрытые мютексом, то для этого RAII есть.
заранее скажу, что про гуарды, или как они в куте называются, qmutexlocker, я в курсе, тем не менее, факт нелюбви кутевцев к экзепшенам и именно в связи с многопоточностью это не отменяет.
Этот нюанс основа архитектуры тулкита. Три кита так сказать: дерево QObject'ов (особенности управления памятью), сигнал-слот (с массой своих хитростей, нужно уметь использовать), евентлупы (источник всей движухи).
me практически не использовал многопоточность на С++.
Сложно сказать, что лучше: додж чарджер 70г.в., ока, или белаз.
Ясно, что использовать Qt целесообразно в Qt приложении. std::thread это так сказать must have, ибо нативная возможность языка. Появился недавно (C++11) потому кода с ним в продакшене не так много, сейчас хотя набирает обороты.
OpenMP очень мощная либа с большим количеством фич, довольно популярная в продакшене, хорошей документацией. Низкоуровневая, что позволяет активно использовать в системном программировании. Для gcc не требует сторонних либ, все компилируется только с добавлением опции компилятору. Мне, лично, по душе описывать многопоточный код директивам: нужен код для многопоточности — взял в блок, описал директивами. Удобно. Довольно сложная, требует знать матчасть многопоточного программирования (мьютексы, семафоры,etc).
Так что выбор субъективен, и эквивалентен выбору твоего дистрибутива.
//P.S еще есть boost. Но благодаря std:thread им можно пренебречь.
Если же говорить о себе, то я чаще всего использовал Qt-шные потоки, ибо чаще всего многопоточность нужна именно в Qt приложении с формачками и прочими гуевинами.
несколько раз использовал OpenMP для параллельных вычислений.
С выходом 11-го стандарта потыкал std::thread, и понял что на приклодном уровне его оченб даже не плохо использовать.
Но чаще всего, я конечно реализую Runnable, чуть реже наследуюсь от Thread :)