Странное торможение параллельных потоков

Темы связанные с инженерными разработками, но не подходящие в другие ветки форума
Boris_K
developer
developer
Сообщения: 281
Зарегистрирован: 28 янв 2015, 14:25
Версия LabVIEW: 2012 Pro

Re: Странное торможение параллельных потоков

Сообщение Boris_K »

Blackman, нет, ничто в проекте не взаимодействует с мышью напрямую. Все графики используют только стандартный функционал для отображения.
Race conditions - опасный и скользкий баг!
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное торможение параллельных потоков

Сообщение dadreamer »

Boris_K, у меня была раньше похожая проблема с индикаторами Vision на Windows XP и LV11. Если интересно, то вот тут подробнее: http://www.labviewportal.org/viewtopic. ... 227#p54227 Решилось всё в два этапа: сперва, чтобы всю программу не переделывать с нуля, я сократил до минимума число Vision'овских дисплеев и избавился от скроллбаров, распихав всё содержимое FP по вкладкам Tab Control'а. Это уменьшило число отрисовываемых объектов на FP за раз. Ну, а вторым этапом, уже позднее, я перестроил полностью архитектуру программы, как советовал AndreyDmitriev:
[b][color=#FF9900]AndreyDmitriev[/color][/b] писал(а):циклы общения с внешним железом зависимы от потока UI. Проблема решается выносом из времякритичных циклов всех элементов, чувствительных к блокировке этого потока.
Не знаю, хотя, насколько уместно это для вашей программы.
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: Странный артефакт с колесом мыши

Сообщение Artem.spb »

Boris_K писал(а):Как оказалось, тут дело в чём-то другом, то есть не во взаимодействии с фронт-панелью. Я в проекте сделал пробный цикл (в параллель к имеющимся), тоже вывел индикатор его текущей итерации. И вот этот цикл притормаживать заставить ну никак не удалось!
можно увидеть упрощённый вариант последней версии? с проявляющимся эффектом.
Boris_K
developer
developer
Сообщения: 281
Зарегистрирован: 28 янв 2015, 14:25
Версия LabVIEW: 2012 Pro

Re: Странное торможение параллельных потоков

Сообщение Boris_K »

Artem.spb, приложил пример. Добавил в исходный пример параллельный цикл с аналогичными индикаторами итерации и макс. периода цикла. Взаимодействие со фронт-панелью есть, торможения (при прокрутке и двигании графика) нет. Даже нагружал его расчётами, и всё равно он продолжал работать со своей скоростью, не реагируя на прокрутку.
Проблема решается выносом из времякритичных циклов всех элементов, чувствительных к блокировке этого потока.
Что конкретно подразумевалось под "чувствительных к блокировке этого потока"? Как это узнать? Тему ту почитал, но конкретного решения что-то не нашёл.
Вложения
With_2nd_loop.zip
(33.12 КБ) 173 скачивания
Race conditions - опасный и скользкий баг!
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное торможение параллельных потоков

Сообщение dadreamer »

Boris_K писал(а):Что конкретно подразумевалось под "чувствительных к блокировке этого потока"? Как это узнать?
Ну, очевидно, что это операции записи в элементы, находящиеся на FP (контролы-индикаторы).
2016-03-08_1-56-24.jpg
Но, скорее всего, основной вклад в блокировку UI потока вносит Property Node, т.к. каждый вызов любого такого узла переключает :labview: на работу с UI потоком, который как известно один на всё приложение.
Обычно во времякритичном цикле загоняют данные, которые нужно обновить, в очередь, а уже в другом параллельном цикле из очереди достают и обновляют нужные индикаторы. Таким образом циклы друг на друга не влияют через блокировку UI.
Boris_K
developer
developer
Сообщения: 281
Зарегистрирован: 28 янв 2015, 14:25
Версия LabVIEW: 2012 Pro

Re: Странное торможение параллельных потоков

Сообщение Boris_K »

Спасибо. А любое чтение лок. переменных и свойств - не должно вызывать блокировку?
Race conditions - опасный и скользкий баг!
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: Странное торможение параллельных потоков

Сообщение Artem.spb »

Нехитрыми перестановками выясняется, что тормозит именно listbox itemnames.
перестановка остальных элементов в нижний цикл не приводит к такому торможению, хотя и замедляет немного.
Даже если i нижнего цикла отправить в качестве значения в listbox, таких тормозов не наблюдается.
Ну и как уже несколько раз говорилось, надо распараллеливать времякритичные операции и работу с интерфейсом.
Boris_K
developer
developer
Сообщения: 281
Зарегистрирован: 28 янв 2015, 14:25
Версия LabVIEW: 2012 Pro

Re: Странное торможение параллельных потоков

Сообщение Boris_K »

Проверил, да, тормоза вызывает запись в property node, но не только запись, но и чтение. Даже если просто поставить чтение item names, ничего не подсоединяя к его выходу, то будут тормоза, аналогичные тем что в первом цикле.
Race conditions - опасный и скользкий баг!
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное торможение параллельных потоков

Сообщение dadreamer »

Boris_K писал(а):Спасибо. А любое чтение лок. переменных и свойств - не должно вызывать блокировку?
Любой вызов Property Node / Invoke Node - это гарантированное переключение в UI поток. А вот прямое чтение / запись контролов и индикаторов (в том числе и через локальные переменные) далеко не всегда переключает этот поток. Здесь дело в том, как :labview: обновляет панель. Для контролов и индикаторов используется промежуточное хранилище (транспортный буфер). При прямом чтении/записи мы по сути работаем с этим промежуточным буфером, а :labview: сам решает, когда скопировать инфу из этого буфера "на панель". Property Node / Invoke Node заставляют :labview: сразу копировать инфу "на панель", делая принудительную перерисовку. Потом эти узлы медленнее и нежелательны во времякритичных циклах.
В той теме, что я приводил выше, в самом конце есть ссылки на пару интересных статей. Есть, например, документ под названием "Improving the Performance of your LabVIEW Applications". Там ближе к концу кратко описан механизм обновления панели.
Boris_K
developer
developer
Сообщения: 281
Зарегистрирован: 28 янв 2015, 14:25
Версия LabVIEW: 2012 Pro

Re: Странное торможение параллельных потоков

Сообщение Boris_K »

А нет ли в :labview: способа полностью вручную обновлять фронт-панель (и считывать с неё), то есть возложить эту функцию целиком на свою программу? Например, когда писал программы с DirectX-графикой (на Blitz Plus, ныне покойном :crazy: ), то сам решал, когда и что перерисовывать, когда синхронизировать экран. И мне это нравилось, это даёт больше свободы. Можно ли аналогично в :labview: ?
Race conditions - опасный и скользкий баг!
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: Странное торможение параллельных потоков

Сообщение Artem.spb »

defer.png
defer.png (11.81 КБ) 10591 просмотр
Boris_K
developer
developer
Сообщения: 281
Зарегистрирован: 28 янв 2015, 14:25
Версия LabVIEW: 2012 Pro

Re: Странное торможение параллельных потоков

Сообщение Boris_K »

А как вообще узнать, будет ли вызов данного элемента переключать в UI-поток? Не нашёл данного аспекта в справке.
Race conditions - опасный и скользкий баг!
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное торможение параллельных потоков

Сообщение dadreamer »

Скролл в данном случае - это ещё цветочки. Вот если нажать ЛКМ на заголовке окна и держать не отпуская, то цикл встаёт аж на 500 мс. То есть, ситуация аналогична этой: http://www.labviewportal.org/viewtopic.php?f=35&t=6651 Убираем Propety Node из цикла и вуаля! цикл не тормозится, хоть сколько нажимай на заголовок. От Defer Panel Updates здесь толку не будет. Это легко проверяется: перед циклом отключаем обновление панели (DeferPanUpdts=True), в процессе работы цикла жмём на заголовок, крутим колесо и т.п., после цикла включаем обновление панели (DeferPanUpdts=False). И видим, что когда мы жали на заголовок, цикл стабильно вставал на 500 мс. То есть, даже при отключенном обновлении панели узлы Property / Invoke переключают UI поток. Отсюда остаётся только один действенный вариант: выносить обновление листбокса в другой цикл и юзать очередь/user event для связи циклов.
Boris_K
developer
developer
Сообщения: 281
Зарегистрирован: 28 янв 2015, 14:25
Версия LabVIEW: 2012 Pro

Re: Странное торможение параллельных потоков

Сообщение Boris_K »

Есть траблы с user events. По-прежнему в некоторых случаях происходит подтормаживание потока, несмотря на то, что он нечувствителен к потоку UI. Обо всём по порядку:

Сделал :vi: который общается со спектрометром, постоянно принимая с него новые спектры. Нужно принимать спектры очень быстро (спектрометр должен снимать с малой выдержкой, например, 3 мс). При этом крайне желательно не пропускать спектры. Использовать user events вынудил сам производитель спектрометра: работа с ним организована через специальную dll, и приход нового спектра обнаруживается как раз через срабатывание user event, reference которого передаётся в dll при вызове нужной функции из неё.

:vi: имеет 2 параллельных цикла, в одном - пользовательский интерфейс, в другом - общение со спектрометром. Между циклами данные передаются через нотификаторы, а также через отлов события value change для контролов (контролов с механикой latch там нет). Ивент-структура только одна, в потоке спектрометра. Сам поток спектрометра не содержит ничего, что могло бы иметь сношения с UI-потоком: нет ни одного терминала, ни одной лок. переменной, ни одного property node. Все вызовы dll настроены как "Run in any thread".

Вместе со спектром, спектрометр шлёт свой аппаратный штамп времени (с разрешением 10 мкс, то есть 0,01 мс), когда этот спектр был снят. По разности этих штампов времени от двух последних спектров, я и определяю, был ли пропуск спектров: программа отслеживает макс. значение этой разности. Ес-сно, оно всегда кратно времени выдержки, т. к. снятие спектров идёт непрерывно.

И на первый взгляд, всё замечательно: поток спектрометра, например, не тормозится на 500 мс, если нажать и удерживать заголовок окна. Вообще не влияет. Но в остальных случаях, при сворачивании/разворачивании, изменении размеров окна, вращении колеса мыши - часто бывают лёгкие тормоза до 30 - 40 мс, максимум до 70 мс. Причём, если выкинуть из :vi: этот user event - симптом пропадает.

Что я только не пробовал - задавать разные значения для приоритета и preferred execution system (в настройках :vi: ), выносить каждый цикл в отдельный :vi: , задав у этих двух :vi: разные preferred execution system. Не помогало.

От безысходности, в диспетчере задач, ПКМ на процессе, выбрал "задать соответствие". И обнаружил любопытную вещь. Если просто снять галку со "все процессоры", и снова её поставить, то тормоза при вращении колеса полностью пропадают, а при других операциях с окном - лишь малые задержки, примерно до 7 мс, и то не всегда. Это на Core i7 920 (8-ядерном). Тестил на другом компе, какой-то 2-ядерный Athlon - там, к сожалению, тормоза не уходят, но всё равно сильно уменьшаются.

При этом сама прога всегда выполняет одни и те же операции со спектрами, и проц сильно не грузит (обычно 1 - 6 %, в диспетчере задач). И при отсутствии описанных действий пользователя, пропуска спектров не происходит никогда.

Можно ли как-то полностью избавиться от описанной пакости?

P. S. Код бы приложил, но там порядка 20 subVI (все они имеют приоритет subroutine), и без спектрометра ес-сно, потестить не получится.
Последний раз редактировалось Boris_K 19 май 2016, 20:35, всего редактировалось 2 раза.
Race conditions - опасный и скользкий баг!
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное торможение параллельных потоков

Сообщение dadreamer »

Boris_K писал(а):Можно ли как-то полностью избавиться от описанной пакости?
Похоже, вы перепробовали почти всё, что советовали когда-либо по этой проблеме. Если найдёте решение, то станете первопроходцем. :wink: А пока есть несколько вещей, которые можно попробовать и посмотреть, повлияет ли это на что-нибудь.
- замена уведомителей на очереди (скорее всего, не поможет);
- вынос цикла получения данных с прибора в отдельный :vi: И запуск этого :vi: через инструменты Run VI / Call By Reference / Start Asynchronous Call (нужно поиграть с опциями); отключите панель SubVI и поставьте приоритет "subroutine";
- увеличение задержки в цикле UI и уменьшение задержки в цикле получения данных (для теста можно задержку убрать полностью);
- компиляция в экзешник и замер врёмен выполнения; если в exe не будет влияния на программу, то может оставить как есть...
- Пуск -> Панель управления -> Система -> Дополнительные параметры системы -> вкладка Дополнительно -> кнопка Параметры пункта Быстродействие -> Дополнительно -> Оптимизировать работу: служб, работающих в фоновом режиме;
- обновление :labview: до самой свежей версии;
- компиляция цикла набора данных в отдельный exe и связь с ним через методы IPC (TCP/IP, UDP, Network Streams, SV, Pipes, Shared Memory и т.д.).

Попробуйте сперва эти варианты, если вообще ничто не поможет, будем дальше думать. И прикрепите хотя бы скриншот основного цикла с небольшими пояснениями (по возможности), чтобы видно было, где User Events, где CLFN, где прочие вещи.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Общие»