Обращение к DataSource в main-потоке

Страницы: 1
RSS
Обращение к DataSource в main-потоке
 
Просьба к разработчикам терминала обратить внимание на это сообщение и дать свои конструктивные комментарии.

Допустим, что у нас есть экземпляр DataSource, который содержит в себе 5-минутные свечки:
Код
local ds = CreateDataSource(classCode, secCode, INTERVAL_M5)

Если ds используется в потоке коллбэков, то есть гарантия, что пока в коде коллбэка идёт работа с этим экземпляром (например, итерирование по индексу от 1 до ds:Size()), данные внутри него (количество свечей, их high, low, close, volume) не меняются.

Вопрос в том, как добиться стабильности внутреннего состояния в main-потоке? Ведь если я запомню в переменной размер DataSource
Код
local size = ds:Size()
перед началом цикла, то в процессе итерирования могут как добавиться новые свечи, так и обновиться старые (скажем, сначала обновилась последняя свеча, а потом добавилась новая). При этом могут возникать неприятные эффекты типа в потоке main прочитали high последней свечи, потом поток коллбэков обновил свечу так, что новое значение close стало больше уже прочитанного значения high, а потом поток main увидел последнее значение close, которое больше прочитанного ранее high.

Не уверен, что будет происходить с содержимым DataSource при смене торговой сессии, скорее всего, ничего хорошего.

Чтобы гарантированно иметь консистентные данные, можно, например, использовать ds:SetUpdateCallback, в котором заранее производить копирование состояния ds или его изменений в другой объект, и складывать в очередь, разгребая которую из потока main до опустошения, можно всегда получить последнее консистентное состояние ds. Сейчас у меня реализован этот вариант, но кажется, что он излишне нагружает скрипт, т.к. свечки нужны в потоке main раз в 5 минут, а обновление свечей в потоке коллбэков идёт постоянно.

Не уверен, что у меня есть 100% рабочий рецепт получения консистентных данных из DataSource в потоке main, но можно пытаться делать многократное чтение данных, когда параметры каждой свечи с номером i читаются до тех пор, пока не окажется, что ds:Size() не изменился и ds:T(i), ..., ds:C(i) совпадают с прочитанными ранее, после чего полагаем, что свеча i актуальна и можно переходить к следующей.

В более сложных ситуациях подобного рода проблему полностью решил бы следующий подход, когда есть возможность запуска функции в потоке коллбэков с API типа следующего:
Код
ExecuteCallback(function() 
  -- обращение к данным ds, которое будет произведено в потоке коллбэков
end)

В языке программирования Java в GUI-приложениях на Swing аналогом является вызов
Код
SwingUtilities.invokeLater(Runnable doRun)

Вопросы/пожелания к разработчикам:
1) рассмотреть возможность введения подобной возможности в терминал;
2) либо отказать, либо реализовать в сжатые сроки.
 
В принципе, ничего не мешает в каждом коллбэке написать проверку типа: если очередь на выполнение, пополняемая из потока main непуста, выполнить функции из неё. У этого подхода есть недостатки:
1) придётся написать в каждом коллбэке строчку, вызывающую работу с очередью функций;
2) если рыночных коллбэков не происходит (например, торги остановились), main не получит требуемый результат, хотя поток коллбэков свободен.
 
Цитата
_sk_ написал:
Вопрос в том, как добиться стабильности внутреннего состояния в main-потоке?
Обработайте в цикле свечки до size-1, а, затем, оставшиеся 1 или 2 (если в процессе обработки в цикле успела закрыться текущая для начала цикла свечка)
 
Цитата
_sk_ написал:
В более сложных ситуациях подобного рода проблему полностью решил бы следующий подход, когда есть возможность запуска функции в потоке коллбэков с API типа следующего:
Делайте через ssort, работает стабильно.
Передаете в ssort таблицу на 2 элемента и заглушку которая вызывает пользовательский колбек. А там итерацию спокойно делаете любых данных.
разрабов в этом плане можно долго ждать, хотя мне бы тоже хотелось функционала из коробки (https://forum.quik.ru/messages/forum10/message28159/topic3225/#message28159)
 
Цитата
Делайте через ssort, работает стабильно.

Спасибо за подсказку!

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

Солидарен.
Страницы: 1
Читают тему
Наверх