Russian Qt Forum

В моей программе пользователи могут соединять сигналы и слоты вручную, и могут при ошибке создать "обратную связь", что приведет к предельной загрузке нескольких нитей - передающей, приемной и системной, обеспечивающей передачу сигналов через очередь (соединение Queued). Передающая, приемная и системная нити - все разные. То есть, в таком случае приложение становится практически неработоспособно, поскольку процессор, даже многоядерный, оказывается перегружен.

Вот вопрос - есть ли проверенные средства обнаружения такой ситуации? Обнаружить обратную связь при подключении во всех случаях невозможно - она может быть через посредников, и может быть вполне безобидной, смотря какие посредники. Кроме этого, теоретически, могут быть и другие причины перегрузки процессора, поэтому нужно найти способ обнаруживать программно такую перегрузку, чтобы иметь возможность остановить неосновные нити приложения, вызвавшие перегрузку. Основная нить должна остаться рабочей.

Важно - способ решения должен быть мультиплатформенным, и вообще крайне необходимо остаться в рамках Qt.

Прямого решения или какого-либо кода я не прошу. Если кто-то что-то подобное делал - буду благодарен за подсказку направления, куда смотреть. Приветствую обсуждение различных идей такого обнаружения.

Неясно что имеется ввиду - помещением события в очередь (свою или другую) занимается та нитка что помещает (посылает queued сигналы).

Можно попробовать отслеживать число событий находящихся в очереди(ях), и из этого пытаться делать какие-то выводы.

хранить карту или список имен (или указателей, что более опасно) объектов, которые уже связаны.
при коннекте проверять есть ли связь с этим объектом. соотвественно все объекты должны иметь не пустой objectName. я бы так делал.
и еще вроде бы в 5 Qt расширили функционал связей connect. Помоему можно получить уже какие объекты привязаны к каким слотам.
Тогда еще проще все обстоит.

Не-не-не... это всё не годится. Я же прямо написал - при установке соединений проверять связи не имеет смысла, поскольку обратная связь может быть вполне легальной, и к перегрузке не приведёт. Более того - одна и та же обратная связь может приводить к перегрузкам, а может не приводить, это уже зависит от настроек участвующих в ней объектов.

Проблема именно в том, что необходимо определять факт перегрузки во время выполнения, никаких других вариантов нет, проблема стоит именно так.

Именно так, как написано - одна нить (на самом деле, не одна) посылает в очередь сигналы, другая нить (тоже, на самом деле, не одна...) их получает, и разумеется есть системная нить Qt, которая обслуживает очередь.


Во всех очередях - нереально. Количество очередей, частота посылки и количество сигналов в них непредсказуемо. Даже при их большом количестве всё может нормально работать. Просто при обратной связи может возникнуть ситуация, когда объекты шлют очень быстро, и обрабатывают очень быстро, в результате растет нагрузка на процессор. И она становится постоянной, поскольку в такой обратной связи ничто не мешает сигналам передаваться (и не должно мешать, если перегрузка не возникает).

Необходимо отслеживать именно перегрузку процессора, существенное снижение его вычислительного ресурса во времени. Возможно что-то с таймером, запускаемым в отдельной нити, и считающим количество выполненных в этой нити операций за определенный интервал времени. Если это количество меньше некоторой величины, посылается сигнал остановки нитей. Но в этом варианте таймер сам должен грузить процессор непроизводительными операциями, поэтому такой вариант мне не нравится. Вариант, при котором таймер считает количество обработанных в единицу времени отправок в очередь... выглядит не очевидным в реализации (к очереди в Qt ведь нет доступа). Тем более, что могут быть нити, которые в норме посылают сигналы медленно.

Вы бы подробней остановились на причинах увеличения нагрузки на процессор, при циклической связи.
А то не очень понятно, в одном случае, как вы пишете, нагрузка растет, в другом не растет. От чего это зависит не понятно. И по подробней, что делают нити и какие данные между ними гоняются.

Зачем это???

От чего в реальности зависит нагрузка - это уже особенности применения приложения. В конечном счёте, это зависит от действий пользователя. Мне не нужно обсуждать допустимость или недопустимость его действий или попытки их запрета. Эта тема для того, чтобы найти возможность программно определить повышенную нагрузку на процессор, и завершить выполнение нитей, которое к этому приводит (я знаю, какие нити надо завершать, тут нет проблем).

Поэтому просьба - не надо выяснять особенности работы приложения. Иначе ветку придётся закрыть, поскольку это будет сплошной оффтопик.

Вы хотите просто узнать загрузку cpu по ядрам и на основании этого завершать свои нити?
А если в настоящий момент процессор нагружает совершенно чужой процесс, а ваши нитки не причем?

Вот
https://support.hyperic.com/display/SIGAR/Home
кроссплатформенный API для определения загрузки процесоора, в том числе конкретными нитями и приложениями. И, да, никакого отношения к Qt он не имеет.

Всё равно имеет смысл их завершать - если другой процесс загрузил процессор по самые никуда, значит моё приложение не может выполнять свои функции, его надо корректно остановить. Это может быть критично. Сам пользователь это сделать не может, но приложению могут достаться кванты времени. Хотя, конечно, идеально было бы знать загрузку процессора конкретными нитями в моём приложении. А еще лучше - процент загрузки процессорам моим приложением. То есть, если оно загрузило процессор более чем на 98%, например - значит оно само останавливает свои нити.

Спс, посмотрю, но хотелось бы в рамках Qt остаться. Использование других фреймворков требует согласования с заказчиками.

У каждой нитки свой EventLoop который запускается в exec, в его очередь и кладут сигналы-события. О каком-то специальном сервисе главной нитки мне ничего не известно  :)

С выводами о перегрузке никто не торопит, это завязано на задачу и в любом случае просто не будет. А вот визуализировать (хоть и в консоли) число ждущих событий во всех нитках было бы очень к месту. Момент создания нитки всегда прекрасно известен, ну даете ей имя и в контейнер указателей. Заводите "наблюдающего" который с каким-то интервалом шлепает всю инфу в консоль, а может и в файл. А там уже смотреть. Для таких задач сначала нужно делать диагностику.

Тут др проблема - если нитка занята, то события таймера могут прорываться очень редко или вообще никогда, независимо от интервала. Поэтому "наблюдающий" - обязательно отдельная нитка. А интервал - доли секунды, какой там перегруз

кстати а не задумывались использовать какую то RTOS для вашего приложения? например Qnx или VxWorks? Под Qnx точно есть Qt.
Както странно у вас должно работать приложение... в определенной ситуации когда нагрузка будет извне, оно просто не сможет работать вообще.

Тут без менеджера соединений не обойтись в вашем случае. Другой вопрос, не порушит ли это шаткое равновесие вашей программы.

И да, менеджер возможно написать лишь имея полное представление о карте коннектов, если можно так выразиться. И вот тогда зацикливаний у вас не будет.

Это не имеет смысла. Я уже три раза написал - я и так знаю, какие нити надо тормозить. Мне надо знать КОГДА это делать. Наблюдая за нитями или очередями я НЕ МОГУ это выяснить. Поскольку это НЕ ДАЕТ информации о перегрузке процессора.

Есть и менеджер коннектов свой, и карта коннектов своя. Всё давно работает еще с 2011 года, равновесие очень устойчивое, и вовсе не шаткое. Но от зацикливаний это спасти не может - никакой менеджер в принципе не в состоянии определить, является ли зацикливание нормальным, или оно приведет к перегрузке.

Если кому-то не понятно о чем идет речь (по реакции я вижу, что не понятно...) - надо представлять эту задачу, как электронную схему, собираемую пользователем. Если пользователь создал положительную обратную связь, взяв выход цепочки из трех (или четырех, или десяти...) усилителей и замкнул его на неинвертирующий вход первого усилителя цепочки - при попадании на вход любого сигнала (на самом деле сразу при включении) схема "возбудится" и превратится в генератор, выдающий на частоте собственных колебаний некий периодический сигнал с амплитудой, почти равной питающему напряжению выходного усилителя. А может быть - пользователю именно это и нужно! Может быть, кроме этой очевидной обратной связи (которую программно можно обнаружить), один из усилителей пользовтель вводит в режим ограничения - и вся схема будет генерировать, но с управляемой амплитудой. Это видно пользователю, но это в принципе невозможно обнаружить программно. Зато можно дополнительными средствами обнаружить факт возбуждения, и выключить схему в такой ситуации. Вот и мне нужно обнаруживать факт перегрузки процессора (что является результатом паразитного "возбуждения"), а не переполнение очередей, установку соединений и т.д... Поскольку и переполнение очередей, и установка ЛЮБЫХ соединений могут быть вполне легальными и к перегрузке процессора не приведут.

То есть, никаких обходных путей нет. Нужно определять факт перегрузки процессора своими нитями. Больше ничего не подходит. Я уже просил - не уходить от этого вопроса. Это только бессмысленная трата времени.

В Т.З. две ОС пока прописаны - Windows и Linux. QNX возможно в будущем. Всё. Больше ни шагу в сторону.

В реальности, если процессор перегружен посторонними задачами - и не должно работать. Ибо это не имеет смысла по сути задачи. Должно тревогу орать... Но если СВОИ нити перегрузили процессор - приложение должно иметь возможность это определить, и остановить эти нити (выдать алерт, сделать запись в лог и т.д.).

Вы в верхнем +1 сообщении сами написали, что хотите невозможного.
Вы хотите дать возможность сознательно сделать зацикливание, но при это избежать зацикливания. Вы уж определитесь чего вы хотите.

PS самый простой пример - пользователь может создать 50 таких рекурсивных генераторов и у вас на любом компе загрузка будет под 100%, но при этом приложение должно работать в штатном режиме.

Вы невнимательно читали. Я НИГДЕ не писал, что хочу избежать зацикливания - потому, что я этого НЕ хочу. Еще раз: зацикливание - НОРМАЛЬНАЯ ситуация. Но в результате ошибки пользователя зацикливание МОЖЕТ приводить к перегрузкам. Я с самого начала четко написал чего я хочу, повторю еще раз - определения ситуации перегрузки процессора этим же самым приложением. Здесь нет ничего про зацикливание. Зацикливание я вижу только у тех, кто не могут понять задачу - зацикливание на попытках решить проблему, которой нет, и которая не была сформулирована...


Нет. Надо остановить "генераторы", пока процесор не освободится настолько, чтобы интерфейс стал достаточно реактивен, выдать сообщение об этом, сделать запись в лог. В расширенной диагностике показать, какие именно соединения привели к такой ситуации.

Всё, мне надоело повторять одно и то же.  Тему закрывать не буду, может кто-то поймет, о чем идет речь, и обсуждение свернет на обозначенную проблему. Но и реагировать на оффтопик больше не буду. Кроме ссылки xokc всё остальное было сплошным оффтопиком.

Если Вы ввели свой термин "перегрузка процессора" никак его не определив, то напрасно Вы рассчитываете на содержательный разговор, все и будет "вокруг да около". Так что фырканье лучше оставить при себе.

Лично я под "перегрузом" понимаю "оверхед", причем солидный, когда нитки вместо полезной работы заняты напр переключениями контекста. Классический пример - создано слишком много ниток. Напр утилита Activity Monitor это прекрасно показывает. Если так то не вижу что обсуждать на форуме - ищите подходящие утилиты для своих платформ и не морочьте голову с доморощенными терминами. Если не так, то поясните какой смысл Вы вкладываете в этот термин, и лучше без нажима, не надо сорить большими жирными буквами.

А может не стоит без раздумий отвергать мысль которая мне кажется вполне здравой. Попробуйте забить очередь напр миллионом сигналов - и Вы получите отличные тормоза (уже на контейнере очереди). Обратный пример - с очередями все норм, но прет оверхед. Как это может случиться? По-моему никак. Напрашивается отслеживать динамику очереди - напр ага, неуклонно растет. А факт оверхеда - ну это уже "все случилось" и хз чем вызвано.

Хотя... чего это я лезу со своими "сплошными оффтопиками"? :)  Все, умолкаю

оффтоп:
Вы не учитываете важную деталь. Даже при загрузке 100% процессорного времени приложение может отзываться нормально. Просто использоваться будет именно 100% :P
У процессора нет понятия "перегрузки", он работает спокойно и на 100% на всех ядрах, а торможение интерфейса - это уже забота программы и ОС.

У вас я вижу лишь вариант ограничить потребление программы. Не оверхед (его невозможно определить, по вышеизложенной причине), а именно потребление. Допустим более 70% мощностей программа жрёт - останавливаем и сообщение пользователю.

А api тут придётся писать самому или использовать готовое платформозависимое. Думаю особой проблемы не составит найти решение под винду - есть диспетчеры задач самописные, исходники открыты, загрузку получить можно.

Пусть будет оверхед - это слово калька с английского overhead, что по сути означает перегрузку. Странно, что термин не понятен, он весьма древний. При некоторых действиях пользователя, которые невозможно запретить, возникает повышенное потребление ресурса процессора, которое снижает реактивность интерфейса до критической - приложением становится невозможно управлять. Это надо обнаруживать и снижать нагрузку на процессор. Изначально я начал тему, чтобы обсудить возможные варианты реализации этого обнаружения.

Ну тут смотрите сами, задача опускается до "обнаружить замирание интерфейса".

То есть нам нужно замерять производительность отрисовки и системы доставки event'ов.

Вполне достаточно будет считать paintEvent в секунду допустим, или же посылать самому себе сообщения через QEvent. При нормальной работе промежуток между посылом и приёмом события будет минимальным. При увеличении промежутка бить тревогу и отрубать работу.


PS хотя сомнения имеются по paintEvent'u, там вроде может и не посылаться перерисовка при статичном интерфейсе.

Это уже ближе к телу. Правда, мне не ясно, как считать paintEvent для всех элементов интерфейса, у меня их множество. Приложение может открыть более десятка окон на двух мониторах, а вообще их количество виртуально не ограничено - что пользователь захочет, то он и откроет. Какие плагины поставит, такие и будут окна открываться. В множестве случаев я не наследую классы этих окон. Впрочем, есть пара окон, которые обязательны, и которые наследуют QMainWindow. Достаточно ли будет отслеживать их паинты? Насколько я знаю, перерисовка в Qt производится только когда меняется содержимое окна, или его перекрытие, или по нему проходит курсор. Но курсор еще должен до него доехать... То есть, если курсор вне моих окон, и в них ничего не меняется - то о перегрузке-оверхеде узнать не получится. Нужен какой-то другой способ.

По поводу paintEvent:
1) я говорил о сомнениях.
2) достаточно у одного окна отслеживать, ведь по сути мы проверяет систему евентов, а не отрисовку.

И вы не рассмотрели второй способ, который я вам предложил - посылка своего QEvent с временем отправки. Если не получаете его в течении секунды - двух, можно бить тревогу, ибо система доставки событий парализована :)

А она точно парализована? У её нити нет повышенного приоритета?

Собственно почему интерфейс отрисовывается - потому что через очередь событий приходит сообщение QEvent::Paint.
Почему интерфейс не отрисовывается или отрисовывается с задержкой - сообщение не доходит или доходит с задержкой.
Вывод - работа очереди событий парализована.

Очередь событий находится в главном потоке приложения и имеет тот же приоритет, что и главный поток. Соответственно при загрузке основного потока очередь событий тормозит и не успевает доставлять сообщение о необходимости реакции на действия пользователя.

Как то так.

Не обязательно. Отрисовка замедлена, потому что сами функции отрисовки не получают достаточно времени. Они, как правило, по сравнению с очередью событий, более тайм-ёмкие.

То есть, надо пробовать...

Обязательно будет гигантское отличие по времени доставки.
Если при нормальном режиме работы отрисовка происходит практически мгновенно (т.е. без тормозов, 24 раза в секунду), то проблема именно в очереди событий.

Отрисовка и доставка сообщения о её необходимости отличаются по времени в разы.

PS кстати тоже как вариант замерять время отрисовки для надёжности, но пока я в сомнениях о необходимости такой меры.

up

Вернулся к этому вопросу. Попробовал для начала замерять время доставки обычных сигналов, и определять ситуацию, когда это время значительно увеличивается. Создал вариант, при котором интерфейс приложения вообще не откликается, и не перерисовывается. На 4-х ядерном процессоре загрузка всего 35-45%. То есть, компьютер работает, Веники живые, но само это приложение можно только прибить - на close главного окна оно реагирует, но больше ни на что. В этой ситуации даже не получается определить время доставки сигналов - они замерзают, никуда не доходят, любые попытки получить отладочную трассировку не имеют успеха.

Делал так - приемник соединен с передатчиком через QueuedConnection и крутит у себя нить, которая шлет сигналы, нагружающие процессор. Нить синхронизируется семафорами, этот код был ранее отлажен, и хорошо работает. Передатчик с такой же нитью посылает через очередь этому приемнику вместе с полезными данными (в тестовом режиме это были пары QString, то есть, довольно объемные данные) временной штамп (в миллисекундах в виде qint64), приемник получает штамп, и если разница текущего времени (QDateTime::currentMSecsSinceEpoch()) и штампа больше 1 секунды, то приемник глушит свою нить. При одной такой паре передатчик-приемник это работает. Но если создать 2-3 таких параллельно работающих соединения, то приемники просто перестают успевать обрабатывать сигналы. И явно передатчики тормозят и не успевают быстро посылать. При этом видно, что занятая память очень медленно растет - то есть, очереди наполняются, но не очищаются. Возможно, что сигнал об остановке таки был послан нити, но он тоже застрял.

Есть ли смысл проверять с помощью QEvent? Его механизм передачи существенно отличается от сигналов? Есть гарантия доставки QEvent при таком замерзании приложения, как описано? Можно ли доставлять QEvent с высоким приоритетом, чтобы обойти замерзшие очереди? Я не использовал формирование QEvent, обходился только обработкой сформированных системно.

Вы в корне неверно поступили. Вместо замера времени по таймеру, вы пытаетесь работать сигналами.

Поясню - вы хотите замерить положение колеса в мире и используете для точки отсчета  это же самое колесо. Это бессмысленно.

Замерять надо в сигналонезависимом методе. Т.е. берём обычный таймер, не Qt. И в нём замеряем/проверяем переменную в которой хранится, допустим, время последней доставки какого-то сигнала.
При приёме сигнала в эту переменную записывается текущее время.

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

PS понятно объясняю, или сумбурно?