Обнаружение перегрузки процессорных ядер

[Гурман]

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

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

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

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

[Igors]

.. и системной, обеспечивающей передачу сигналов через очередь (соединение Queued).

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

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

[Fregloin]

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

[Гурман]

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

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

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

[Гурман]

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

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

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

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

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

[Old]

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

[Гурман]

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

Зачем это???

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

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

[Old]

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

[xokc]

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

[Гурман]

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

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

[Гурман]

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

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

[Igors]

..и разумеется есть системная нить Qt, которая обслуживает очередь.

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

Во всех очередях - нереально.

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

Но в этом варианте таймер сам должен грузить процессор непроизводительными операциями,

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

[Fregloin]

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

[Bepec]

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

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

[Гурман]

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

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