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

[dadreamer]

В вложенном VI не менее странное поведение Event Structure.
1. Генерация User Event симулирует Mouse Scroll Event, которое как бы еще не было доступно в 2012.
2. User Event зарегистрировано Event Structure.
3. Обработчика User Event в явном виде нет.

LabVIEW 2013 Bug Fixes:

Non-handled, registered dynamic events reset the event structure timeout

[Blackman]

dadreamer, cпасибо за подсказку.

[Boris_K]

Artem.spb - в том примере, что вы дали (Parallel3) значения в контролах считываются 1 раз, до цикла. А как тогда сделать, чтобы считало с текущими значениями? (признаться, ещё не работал с queue).

[Artem.spb]

Artem.spb - в том примере, что вы дали (Parallel3) значения в контролах считываются 1 раз, до цикла. А как тогда сделать, чтобы считало с текущими значениями? (признаться, не до конца ещё понял, как работает queue).

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

[Boris_K]

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

[Artem.spb]

ими сейчас ничто не мешает крутиться параллельно

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

[Boris_K]

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

взаимодействие с интерфейсом - это значит что там есть хотя-бы один терминал (контрола/индикатора)? А если вместо него будет локальная переменная например?

[Artem.spb]

Хоть prop node, хоть локальная.
Это всё равно обращение к элементу на FP.

[Boris_K]

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

А здесь писали, что очередь не подойдёт если циклы асинхронные, то есть работающие каждый со своей частотой: http://labviewportal.org/viewtopic.php?p=62701#p62701

[Artem.spb]

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

[Blackman]

А здесь писали, что очередь не подойдёт если циклы асинхронные, то есть работающие каждый со своей частотой

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

[Boris_K]

Вопрос в том, что и зачем передавать между циклами.

Информацию для расчёта, а обратно - результаты.

Именно асинхронность потоков (в смысле работающих с разной частотой) позволяет оптимизировать работу приложения в целом.

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

[Artem.spb]

Вопрос в том, что и зачем передавать между циклами.

Информацию для расчёта, а обратно - результаты.

общий случай я уже описал

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

[Boris_K]

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

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

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

[Blackman]

Все описанные случаи (прокрутка Scrollbar, вращение колеса, перемещение графика курсорами) так или иначе связаны с манипуляциями мышью.
Если нет прямых видимых кусков кода взаимодействия с мышью, может быть они спрятаны в subVI?