Russian Qt Forum

Имеется н не сколько потоков,  обменивающихся данными через сигналы слоты. Работает все нормально,  но через какое то время соответствии перестают отвечать на сигналы.  В чем может быть проблема?

Возможно где то сигналы бегают к слотам, но через какое то они накрывают поляну с водочкой и пивасиком и перестают бегать. Их мобильность падает на 98%, а те, кто всё таки доходит до слотов, не могут передать ни одного вразумительного параметра трезвому и злому слоту.

PS телепаты в отпуске, маразматиков нету, телепортов тоже пока не придумали.

Запусти анализатор потоков и посмотри кто заблокирован.

А можно и мне ссылочку на анализатор потоков?

Хотя бы Intel Thread Profiler (http://software.intel.com/ru-ru/articles/using-intel-thread-profiler-for-win32-threads-philosophy-and-theory/)

Хм. А не проще тупо лог вести в файл? :) Профайлер на то и профайлер, что он анализирует быстродействие.

Ввод/вывод неявно синхронизирует потоки.
Заблуждаешься, профайлер нужен для сбора данных о работающей программе.
В данном случае, если потоки не заблокированы, то ошибка в алгоритме и обработке очереди сообщений.

Кхм. Вопрос, а как ввод/вывод неявно синхронизирует потоки? Пожалуйста подробнее.

system call

И? Поясните мне пожалуйста, как 2 рассинхронизированных потока смогут синхронизироваться при записи в 2 разных файла?

PS мб вы имели в виду, что имеется шанс в 20%, что потоки на некий момент времени могут синхронизироваться и шанс в 80% что они могут рассинхронизироваться при этом?

PPS или вы мб знаете больше чем я об асинхронных системных вызовах и о том, что они асинхронные?

Внутри std::cerr, std::cout, лежит системный вызов write.

Ну свалить в консоль испускаемые сигналы и таким образом убедиться что они были испущены, но не дошли до цели. Просто тормознуться когда висит и посмотреть чем занята каждая нитка. Мало информации чтобы что-то рекомендовать конкретно

Эмм.. я как бы говорю о системных вызовах асинхронной записи в файл, а вы? :D

PS а по теме - достаточно дебагера, чтобы узнать где что завяло.

Вызов системной функции не атомарная операция?
В случае, если два потока захотят выполнить одновременно системную функцию, один из потоков не заблокируется на время выполнения системного вызова?

Неясно откуда/причем здесь async  :)  Какое-то выравнивание на I/O есть, даже если пишут в разнве файлы (устройство-то одно). Однако этот эффект может быть очень всяким (иногда и нулевым). Не думаю что правильно называть это "синхронизацией".  

Нет, не атомарная (не lock-free)
Может и нет (с печальными последствиями). Для таких вызовов в доке и хедерах указано "not thread-safe"

async здесь потому, что потоки то рассинхронизированы. Точнее я неудачно выразился - async относилось к вызовам в потоках, а к записи отношения не имеет :)

И если по умолчанию, то запись в файл кешируется. И соответственно *блокирование вызовов не произойдёт. :)

А если и произойдёт, то одномоментная синхронизация ничего не даст. Вообще. Ибо в следующий момент будет рассинхронизация. Любой поток в системе может вот так случайно синхронизироваться :D
Было у меня пару раз явление под названием гонка потоков :D И представь, программа целую неделю работала и потоки были синхронизированы. Ан нет, потом что-то внесло изменения в их устоявшееся сообщество и они рассинхронизировались => крах программы.

И да - с чего начался спор то - ничего вывод не синхронизирует :D А если и есть влияние то оно не выходит за обычные рамки вероятности.

Это мне что-то напоминает
:) :)

Я говорил, что происходит скрытая синхронизация, т .к. системные вызовы работающие с I/O производят блокировку.
Если множество потоков будет делал частые системные вызовы, то потоки будут влиять друг на друга.

Igors - приведи своё мнение ) Я с удовольствием почитаю :)

Дмитрий я тебе по секрету скажу - система вызывает потоки согласно свободным ресурсам и приоритетам. Так что синхронизация происходит на уровне уже самой системы :D

PS ну сам подумай головой - всё в ОС контролируется системными вызовами. Qt же является лишь надстройкой :D