Средства разработки многопоточных скриптов в QUIK.

Обработка колбеков в OS_Quesha.
  Реализована эта обработка в соответствии с рекомендациями разработчика QUIK по использованию очереди параметров колбеков, которые обрабатываются в пользовательском потоке main.
  Особенности обработки колбеков в OS_Quesha следующие:
1) очередь реализована таким образом, что запись (из основного потока QUIK) и чтение (из потока main) в ней выполняется без синхронизации (никаких лишних переключений возможных при синхронизации), но корректно;
2) поток main активируется сразу после записи в очередь (не дожидаясь истечения интервала времени его ожидания в функции аналогичной sleep).
  Понятно, что основной поток при этом не блокируется,  а реакция в main на колбеки реализована с минимальными задержками (в существующей архитектуре QUIK).

Что имеется ввиду?
Пока объект помещается в очередь (буквально - записывается значение в таблицу Lua) или читается из очереди, другой поток стоит. От переключений не ушли ))

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

  Ну! Пронесло    Хорошо, что есть достойный конкурент. А то уже я стал бояться, что вы выкатите такую сумму, что мне придется забросить все свои дела и заняться этим полезным

После более 28000 прочтений данной ветки, мне показалось странным, что не был задан вопрос: почему OS_Quesha декларируется как операционная система реального времени?

Ответ.
    1. Разработка любых роботов, в том числе роботов для фондового рынка это разработка программ (систем) реального времени, в которых обрабатываются внешние сигналы (информационные потоки) с минимальным участием человека.
    2. Существуют различные определения ОС. Одно из них (например, на сай-те http://osys.ru/os/1/ponyatie_operatsionnoy_sistemy.shtml) следующее:
«Операционная система (ОС) - комплекс системных и управляющих программ, предназначенных для наиболее эффективного использования всех ресурсов вычислительной системы (ВС) (Вычислительная система - взаимосвязанная совокупность аппаратных средств вычислительной техники и программного обеспечения, предназначенная для обработки информации)».
 Это определение краткое, емкое и, если под ВС понимать Windows, а также установленный в нем QUIK, то оно полностью определяет описанное в начальном комментарии ветки.
   3. Реальное время в операционных системах — это способность операционной системы обеспечить, в заявленной сфере ее использования, требуемый уровень сервиса в определённый промежуток времени.
   При создании OS_Quesha были учтены следующие известные, основные требования к системам реального времени:
 1) обеспечение предсказуемого времени обработки непредсказуемо возникающих внешних событий (обеспечен контроль ограничений на время выполнения циклических функций OS_Quesha; причем, для каждой функции может быть свое такое ограничение); это требование самое существенное, классифицирующее систему как СРВ;
 2) надежность (последнее по времени изменение ядра OS_Quesha было внесено в мае 2019г.);
 3) устойчивость функционирования при сбоях аппаратуры и программ (реализованы средства создания и использования контрольных точек при многопоточной обработки данных);
 4) обеспечение обработки большого количества входных и выходных потоков данных, на обработку каждого из которых в отдельности, может требоваться незначительные вычислительные ресурсы (реализован режим псевдопотоков);
 5) обеспечение непрерывности функционирования систем (OS_Quesha, при ее эксплуатации, работает без перезапусков в течение месяцев, до очередного обновления Windows);
 6) учет динамичности таких систем (в OS_Quesha обеспечена возможность изменения схемы обработки данных в процессе ее функционирования);
 7) контролируемость состояния систем (в OS_Quesha обеспечен контроль утечки памяти, блокировок и зацикливаний потоков, а также состояния очередей взаимодействия П/П).

 Почему бы нет. Есть и такое мнение. Пошарьте в сети.
-----
 1. То есть, вы утверждаете:
   1) программа торгового робота не является программой реального времени);
   2) что торгового робота в Windows, в QUIKе написать невозможно.
   Читайте (обращая внимание на фразу "в заявленной сфере ее использования"):

Программа, работающая на железке без RTOS и/или написанная на языке со сборщиком мусора - не работает в реальном времени. Написать робота в таких условиях можно, но говорить что он риалтаймовый - нельзя, в определение риалтаймовости не вписывается.


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

Артем, Кто Вам сказал эти глупости? Каким образом сборщик мусора может помешать работе в реальном времени? Разве что написан криворукими бездарями. Тем более, что диспетчер памяти идеологически как раз функция ОС.

Не знаю, что там у Вас "в определение риалтаймовости вписывается", но я когда-то был включён в соавторы бортовой операционки, которая так и называлась: "ОСРВ" (или RTOS, если угодно). А свой "фон общей турбулентности рынка и вариативность результатов торговли" засуньте лучше куда-нить подальше - Вы в этом абсолютно нихрена не понимаете. Реальное время не имеет никакого отношения к придурочной технологии HFT.

  Незачет.  Приходите следующий раз .

Владимир, длина среза торговых данных, с которыми работает робот - один из гиперпараметров. По аналогии можете представить какие другие переменные являются гиперпараметрами.

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

Владимир, вот такие как вы профессиАналы делают сборщик мусора простым инкрементом, а потом недоумевают почему память течёт. Интересно что вы создателя Лиспа сюда упомянули, при том что в Лиспе сферический в вакууме сборщик мусора, и который тормозит исполнение скрипта, и сканирует все переменые на предмет референсов, и не может поймать острова памяти, и вручную не выключается.


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

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

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

Владимир,Эх помню как тоже сначала пытался ловить тики, чтобы не прозевать самую лучшую цену, вместо одной заявки скрипт только и делал, что ставил, снимал заявки пока не поймает цену, дрочилово то еще было. Потом как вы начал выставлять заявки по ценам спроса/предложения, но после нескольких раз "гонок" с рынком, эту идею тоже отбросил. Сейчас при наличии сигнала просто бью по рынку, всего одна заявка которая тут же превращается в сделку, и наступило счастье..

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

BlaZed, Он так и делает, но даёт новый сигнал. Я же говорю, что эта сволочь изобретательная!  Причём там довольно хитрые зависимости: иногда по истечении таймаута нужно просто не снимать заявку, а иногда не пускать новую. Да и процесс формирования сигнала довольно сложный. С продажей проще - там алгоритм тиковый, а вот на покупку, как правило, свечной, да ещё и хрен знает от какого таймфрейма прилетевший. Обычно со второй или с третьей попытки сделка всё равно происходит (чуть дороже или чуть дешевле), да и не так часто это происходит (2-3 раза в день), так что пока таке поведение не очень раздражает, но уже начинает надоедать.

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

Владимир, если не стесняетесь добавить в логику ценовой политики рассчет стоимости плеча и сделок репо, то шорты нетрудно добавить - они просто инверсия лонгов. Не считая ситуаций когда прибыль съедается комиссией, где по лонгам потери там по шортам прибыли.

Уважаемые участники дискуссии, призываем Вас сохранять корректный тон своих высказываний!

Если не внемлете просьбе - простым удалением сообщений (как сейчас) отделаться не получится. Хотите продолжать общаться на нашем форуме - будьте любезны прислушаться. Заранее спасибо за Ваше понимание.

Реализация диалога в OS_Quesha.

    Одной (но не единственной) причиной реализации многопоточности OS_Quesha было: отсутствие в QUIK нормальных средств создания диалога.
  Тот, кто рискнет использовать таблицу QUIK для создания диалога, точно, легких путей не ищет и это подтверждается многочисленными, многогодовыми обсуждениями на разных форумах тех многих проблем, которые при этом возникают.
  Когда мне пришлось перейти на QUIK (в 2019г.), для меня быстро стало понятно, что, то время, которое уйдет на «кувыркание» с таблицами QUIK, лучше потратить на разработку многопоточности, обеспечивающей, наряду с простой реализацией диалога, решение и других задач перевода моего робота на QUIK.
  Возможность порождения в OS_Quesha отдельного потока, обслуживающего диалог, обеспечивает простоту использования существующих бесплатных графических пакетов.  В OS_Quesha был выбран «легкий» (код менее 2Мб) пакет IUP. Этот пакет в текущий момент стабилен и в нем есть версия для работы в Lua. При использовании данного пакета в отдельном потоке, никаких проблем я не обнаружил. Те графические возможности, которые он обеспечивает, для меня, оказались более чем достаточными.
    Форма диалога OS_Quesha запускается в отдельном потоке (никак не связан-ном с основным потоком QUIK, обслуживающим все колбеки и таблицы QUIK), отдельно от окна QUIK и имеет следующий вид:

В ней есть следующие элементы:
1)  меню системы состоящее из двух частей:
-  служебной: Рынок ЦБ, Отладка, Система
-  прикладной (пользовательской): Меню1(образец), Меню2(образец)
2)  поле вывода сообщений диалога;  в это поле выдаются сообщения-ответы на вводимые команды, а также сообщения о критических ситуациях в системе;
3)  поле ввода команд; это поле является командной строкой и используется для ввода сложных команд;    
   строки, не являющиеся служебными командами OS_Quesha, считаются командами приложения и передаются в функцию cmd_OS_Quesha разбора и выполнения команд приложения, описанную в шаблоне TS_QUIK.lua;
4)  поле вывода сообщений системы; в это поле выдаются сообщения о ситуациях, возникающих в системе, не связанных с диалогом.

  Всё вводимое и выводимое полей рабочего места пользователя сохраняется в потокобезопасном журнале диалога OS_Quesha с фиксацией времени возникновения с точностью до 1 миллисекунды.
   Диалог создается на основании его описания (в табличном виде), представленном в шаблоне TS_QUIK.lua, в котором определяются следующие характеристики:
1)  структура меню системы («дерево» меню) и реакции на вызовы его команд;
2)  размеры всех полей диалога;  свойства окон вывода сообщений (очередь/стек и т.д.);
3)  пользовательские меню (примеры Меню1(образец), Меню2(образец)) с заданием пользовательских функций, обрабатывающих команды этих меню (в том числе с заданием любых объектов пакета IUP);
4)  пользовательская функция разбора сообщений поля ввода команд, отлич-ных от служебных.
----
При необходимости, OS_Quesha может быть запущена без формы диалога (это задается в глобальных настройках системы) и тогда все сообщения системы выдаются непосредственно в QUIKе функцией message, но журнал системы при этом ведется как обычно.

 Ну, не буду же я здесь описывать пакет IUP. В его описании есть события.

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

Структура меню классическая.
Читайте:
И так как диалог работает в отдельном потоке, то никаких "отвисаний от команд, пришедших даже из первого уровня иерархии".

TGB, Да очень просто: таблица по тикерам и есть меню. А дочерние уже содержат информацию по выбранному тикеру. Но, поскольку она бывает довольно объёмная, неплохо было бы иметь и дочерние уже от него (например, по сделкам, по свечам. И редактировать в них кое-что не мешало бы.

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

 В виде строки можно представить любое дерево
 Где проблемы?