LabVIEW Portal

dadreamer писал(а): ↑11 июн 2020, 22:29 ujin, в этом простом не происходит никакой работы с ресурсами, к которым может быть одновременный общий доступ и следовательно состояния гонки, так что его можно юзать хоть реентерантно, хоть "как обычно". Это целиком воля программиста. Просто если он не реентерантный, то все одновременно запущенные экземпляры будут выполняться по очереди (т.к. датаспэйс у такого ВИ один). Это может несколько сказаться на производительности. Если бы был реентерантный, то насоздавал бы клонов (по клону на каждый экземпляр) и они бы выполнялись одновременно. Это было бы быстрее. Но тут уж совсем простой , так разница по временам должна быть мизерная, потому можно этой опцией вообще пренебречь.

Ну, и действительно, если вышестоящий вызывается параллельно и дёргает этот SubVI, то True-реентерантности не получится, т.к. будет выполнять этот SubVI по очереди (как я выше и написал).

Если уйти максимально в глубину то реентрантные vi могут быть в многопроцессорных системах со своими блоками оперативной памяти, к которым возможен одновременный доступ.
Все остальные выполняются процессором так же псевдопараллельно. Т.е по факту последовательно. Даже если есть процессор многоядерный, все-равно доступ к ОЗУ, дискам последовательный.
Реентрантные vi в связи с этим будут так же выполняться последовательно, но для нас это будет выглядеть параллельно. Если нагрузить много клонов с одинаковыми правами и без циклов ожидания, они так же затормозят выполнение друг друга.
Реентантный vi имеет как Вы указали свой датаспейс, вот и все его принципиальное отличие. В данном случае возникла ситуация, когда им всем понадобился один ресурс, но при этом они не перестали быть реентрантными - это принципиальная неточность.

Я написал ровно то, что пишут NI в своих документах: Reentrancy: Allowing Simultaneous Calls to the Same SubVI Первым абзацем там как раз то, что я выше и написал. Однако я на всякий случай (предпочитаю ясность) состряпал вот такой примерчик: В примере сейчас у Саба нет реентерантности. Пускаем Мэйн, пускаем SubVI's и видим, что все три саба выполняются друг за другом, т.е. по очереди. Открываем Саб, устанавливаем ему любую из двух опций реентерантности, сохраняем. Пускаем Мэйн, пускаем SubVI's и все три саба начинают выполняться одновременно. По-моему, всё логично и так это и должно работать. Причём я это часто использую в своих проектах, запуская асинхронно, когда требуется задействовать несколько систем (узлов) установки одновременно. Если бы это не работало, то механизмы бы двигались по очереди, но подобного не происходит. Имею именно параллельную работу устройств (в необходимых временных рамках). Не буду спорить, параллельный запуск множества клонов (потоков) (ну, то есть многопоточность) может несколько замедлить работу программы в целом, но на современном железе это, как правило, не ощущается. Сам при старте запускает с десяток потоков (это можно в логе посмотреть) и завершает их только при выгрузке. Да и множество процессов (служб) в ОС работают в многопоточном режиме, т.к. требуется одновременный доступ к ряду ресурсов (наиболее яркий пример - реестр Винды, который физически состоит из нескольких файлов, но его одновременно дёргают десятки процессов).

ujin писал(а): ↑14 июн 2020, 05:42В данном случае возникла ситуация, когда им всем понадобился один ресурс, но при этом они не перестали быть реентрантными - это принципиальная неточность.

Вашу мысль я уловил :) Просто Андрей мог сформулировать свой посыл маленько иначе: на исследуемом SubVI образуется "узкое" место (как горлышко у бутылки) и параллельно запущенные экземпляры вызывающего могут "застрять" (на несколько мс) на вызове этого SubVI, если у него отключена реентерантность. В итоге получится не совсем ожидаемое разработчиком поведение (если только это не сделано специально).

Reentrant VI выполняются не параллельно, не последовательно, а одновременно

вот так с выяснения причин отсутствия кнопки скатились на споры про реентрантность :)

Blackman писал(а): ↑14 июн 2020, 15:11 не параллельно, а одновременно

а чем параллельность от одновременности отличается?

И уже несколько раз замечал тут бирюзовые иконки системных функций. Это фича 17, или это в настройках меняется?

Artem.spb писал(а): ↑14 июн 2020, 15:20И уже несколько раз замечал тут бирюзовые иконки системных функций. Это фича 17, или это в настройках меняется?

Тоже интересно. На скриптовых нодах такой цвет, но чтоб на всех... Есть какое-то хитрое свойство, чтобы нативный жёлтый на свой поменять?

Перетащил сниппет, у меня все жёлтые...

dadreamer писал(а): ↑14 июн 2020, 15:27 Перетащил сниппет, у меня все жёлтые...

та же история, но я в 18 затаскивал, вот и предположил, что это именно в 17

dadreamer писал(а): ↑14 июн 2020, 15:27 ... Есть какое-то хитрое свойство, чтобы нативный жёлтый на свой поменять?

Хитрого нет. Есть стандартный - LabVIEW.ini

diagram.primColor=CCFFFF

Blackman писал(а): ↑14 июн 2020, 19:28diagram.primColor=CCFFFF

Спасибо. Ни на ni.com, ни на лаве не встречал эту опцию. После гуглинга нашёл:
https://labviewwiki.org/wiki/LabVIEW_co ... .primColor
https://labview.brianrenken.com/INI/color.htm
Можно нормально так стилизовать под себя.

Blackman писал(а): ↑14 июн 2020, 19:28 Хитрого нет. Есть стандартный - LabVIEW.ini

diagram.primColor=CCFFFF