Как ждать изменение глобальной переменной?

[doupiu]

Всем привет!
По мотивам https://community.bablosoft.com/topic/26165/помогите-оптимизировать-код-запросы-к-бд

Код скрипта имеет вид:

Задача: скрипт должен ждать, пока глобальная переменная STOCK станет true, или пока не пройдет 10 секунд. Изменение глобальной переменной происходит в другом потоке. Всего в скрипте 50 таких ждущих потоков.

Проблема: ранее у меня обмен информацией между потоками осуществлялся через БД, и такой цикл выполнялся не 10, а 10-25 сек, что я связывал с нагрузкой на БД (50 потоков долбятся в БД каждые 100 мс). Я переделал скрипт на опрос глобальной переменной, но нагрузка снизилась незначительно. Привожу пример результатов скрипта, указанного выше:

То есть 100 циклов по 100 мс в действительности длятся 16-17 секунд вместо 10 секунд!

Вопрос: как можно оптимальнее решить исходную задачу? Делать, условные, 10 циклов по 1 секунде не могу, так как нужна очень быстрая реакция на изменение глобальной переменной. Может быть в BAS можно реализовать что-то типа await? Пытался решить задачу с помощью JS, но кубик "Выполнить код" даже не позволяет использовать setTimeout. В общем буду рад любым идеям, как сохранить и быструю реакцию на изменение глобальной переменной, и чтобы цикл не создавал такой нагрузки.

[sergerdn]

@doupiu

Вообще, это проблема в Javascript, и в BAS в том числе, когда речь идет о ожидаемом времени срабатывания чего то.

Примеры:

• Действие спать одну секунду будет выполняться не одну секунду, как ты думаешь, а не менее одной секунды.
• Даже если ты вызовешь функцию setTimeout с временем срабатывания 10 секунд, функция сработает точно не ранее, чем через это время, а не через 10 секунд. А может, теоретически, и через полчаса.

И так далее и тому подобное.

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

Я бы попробовал использовать брокеры сообщений, пример RabbitMQ. Когда основной поток отправляет некое сообщение, а другие ждут, пока его получат в блокирующем режиме.

Но это все тоже будет работать не очень надежно, так как природа потоков.