TGB (Все сообщения пользователя)

  Да.

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

А вот и подтверждение этому из разных веток:
1) Опять ошибка получения кол-ва ордеров скриптом: https://forum.quik.ru/forum10/topic6503/ ;
2) [BUG] getFuturesHolding: ошибка в работе: https://forum.quik.ru/forum10/topic6526/ .
  Ошибки, описанные в упомянутых выше ветках, скорее всего, ошибки синхронизации функций API QLua. И ошибки такого вида, возможно, имеются и в других функциях API.
  Вообще, все функции API работы с QUIK из QLua должны быть потокобезопасными  из-за того, что к ним могут обращаться из нескольких одновременно запущенных скриптов (работающих в разных потоках). Причем, объекты синхронизации в таких функциях должны локализоваться в месте, общем для всех скриптов, и это место точно не global_State и тем более не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов пользователя массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией.

 Реакции поддержки на просьбу нет.
 Ее трудно выполнить? Или поддержка считает, что выше написанное, не относится к обсуждаемому в данной ветке?

------------
-----------------------------
 Выше приведенные комментарии, скорее всего, означают, что функция getDepoEx не является потокобезопасной. Вообще, все функции API работы с QUIK из QLua должны быть потокобезопасными  хотя бы из-за того, что к ним могут обращаться из нескольких одновременно запущенных скриптов (работающих в разных потоках). Причем, ! обращаю особое внимание разработчиков, что объекты синхронизации в таких функциях должны локализоваться в месте, общем для всех скриптов, и это место точно не global_State и тем более не lua_State.
----
  Просьба к поддержке, довести данный комментарий до разработчиков QUIK.

    Вы меня заинтриговали своей версией QUIK. Пожалуйста, еще раз проверьте версию QUIK, в которой вы работаете. Но если вы подтверждаете эту версию, то укажите брокера, через которого вы работаете. Если вы подтвердите номер версии QUIK, то это, наверное, Центробанк РФ   . Каким образом вы можете работать в QUIK версии на два шага более новой, чем официальная производителя ARQA в текущий момент (на 06.06.21), для меня большая загадка. Но, возможно, мне что-то неизвестно. Кто-нибуть, возможно, поддержка QUIK, может объяснить, как такое бывает?

  Я как пользователь. Хотел вам помочь. Похоже, не получилось.

  Где вы взяли версию 8.13.3.1, если последняя официальная версия на сайте ARQA  8.13.1 (8.13.1.16) от 19.04.21?

 74 сообщения и нигде не указана версия QUIK, в которой запускается программа в которой происходит непонятное. Версию QUIK следует указывать обязательно.
     Если вы работаете с QUIK версии >= 8.5 и < 8.13.1.16, то в них есть ошибка синхронизации, которая может проявляться в виде сбоев (смотрите ветку Отладка QUIK 8.13 ...).

Средства обеспечения устойчивости роботов, создаваемых в OS_Quesha
  Устойчивость (к сбоям аппаратуры, к ошибкам программ и т.д.) торговых роботов является одним из важнейших требований к ним. Программным средством обеспечения ус-тойчивости является контрольная точка. Контрольная точка программы это значения ее переменных (состояние программы), возникшие при ее функционировании и сохраненные в энергонезависимой памяти  для возможности продолжения работы этой программы, начиная с сохраненного состояния, после ее перезапуска по любой причине (сбой аппаратуры, программная ошибка, и т.д.). В идеале, реализация контрольных точек должна быть такой, чтобы работа программы, при включенной контрольной точке, с перезапусками, возникающими в ней по любой причине, функционально не отличалась бы от ее работы без перезапусков. Реально, этот идеал недостижим, и, используя контрольные точки, можно только уменьшить вероятность нарушения функционирования программы при ее перезапусках. Предположим, что только те сбои программы,  моменты, возникновения которых попадают в интервалы времени фиксации ее контрольных точек,  могут нарушать, из-за неопределенности результата такой фиксации, возможность продолжения ее функционирования. Тогда вероятность нарушения функционирования программы с контрольной точкой пропорциональна длительности фиксации ее контрольных точек. Поэтому в OS_Quesha разработаны специальные решения по уменьшению длительности фиксации контрольных точек.
  Для обеспечения контрольных точек многопоточных приложений в  OS_Quesha используются:
1) служебная папка хранения состояния системы stateOS, в которой размещаются файлы для хранения этого состояния;
2) пакет сереализации таблиц Lua;
3) функции работы с состоянием системы.
 Файлы хранения состояния текстовые и могут при необходимости анализироваться в любом редакторе. Содержимое этих файлов это таблицы состояний функций, ведущих свои контрольные точки,  записанные в соответствии с синтаксисом QLua. Рекомендуется состояния функций, работающих в разных потоках, фиксировать в различные файлы состояния. Файлы состояния, имена которых начинаются с символа @, сохраняют инкрементные состояния. Такие состояния могут быть использованы в случаях больших объемов сохраняемых в них данных. Они обеспечивают быструю запись в их файлы, только возникающих в них изменений. Таким образом, в  OS_Quesha обеспечивается независимость длительности фиксации контрольных точек от их размеров.  Фиксация контрольных точек функций потобезопасная и выполняется в отдельном потоке. Например, фиксация таблицы состояния размером в 100 элементов (строки длинной не более 400 символов и числа) выполняется за ~1 млсек.  Для создания файла состояния, удаления, записи в него таблицы состояния, чтения состояния при перезапуске OS_Quesha, используются основные функции:
1) Очистить / реорганизовать файл состояния;
2) Запись (создание)  контрольной точки в файл;
3) Чтение файла контрольной точки.
  Для управления режимом запуска OS_Quesha в ее глобальных настройках существует параметр Restore_OS_QLua. В этом параметре используются два младших разряда. Нулевой разряд: 0 - запуск (без учета истории функционирования); 1 - перезапуск (продолжение работы).  Первый разряд:  0 - не сжимать файлы инкрементных состояния OS при пе-резапуске; 1 – сжимать. Операция сжатия файлов инкрементных состояний обрабатывает, в момент перезапуска OS_Quesha, список команд изменений их состояний и записывает в них, получившиеся итоговые таблицы состояний.
   В шаблоне TS_QUIK.lua демонстрируется использование инкрементной контрольной точки при обработке лимитированных заявок для хранения истории их состояний с учетом событий, возникающих в QUIKе при обработке этих заявок.
   В описании модуля сереализации, представленного ранее в данной ветке, приведена общая схема реализации контрольной точки циклических функции (а-ля main), исполь-зуемых в  OS_Quesha.

  У меня есть, смутное, подозрение, что вы слабо представляете, что мне известно о вариантах представления графов. На самом деле, мне стал не интересен этот диалог. Но я ставлю 99 против 1, что последний комментарий будет ваш    Сдаюсь  

 Способен. Уже ответил. Прочитайте еще раз:
-----
Зачем вы требуете продолжение "банкета"?
Читайте:

 Я это реально делал и не один раз.

 Кто-то сказал, из великих (цитата не точная): «ОГРОМНЫЙ опыт – это тяжелый груз»  

 Я думаю, что вы не правы. Но вы можете считать, что правы   . Ну и ладно. Каждый из нас, наверное, может иметь свое (особое) мнение и это нормально.

 Заявление сильное. Но, конечно, вы так можете думать   .

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

  Собственно, ваши проблемы вам и решать.

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

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

 Интересно, что вы делаете с тысячами командами. Вы что, тетрикс реализовали

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

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

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

Реализация диалога в 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, но журнал системы при этом ведется как обычно.

 У поддержки есть все возможности быстро навести порядок на форуме и мы это увидели.

  Все напряженно    ждут.

 Если заменить в выше написанном «реалтаймовость» на высокочастотность (смотрите ее описание в сети) , то,  с написанным, я, в основном, согласен.
  Однако, если обсуждать не стратегии торговли, а средства их реализации, то такие средства должны обеспечивать достаточно быструю реакцию на события, происходящие на фондовом рынке. Конкретно, в экспериментах (с включенным мусорщиком QLua) проверено то, что, в OS_Quesha интервал времени между событиями OnParam (это самые частые события в QUIK) и записью 18 параметров по 24 бумагам в их циклические буфера, менее 1 млсек. c вероятностью более 0,99. При этом, в колбеках OnParam выполняется только неблокирующая короткая запись параметров бумаг в очередь, а все остальное выполняется в main. Наверное, для большинства пользователей QUIK, такая скорость реакции вполне приемлема.  Таким образом, как было мною ранее написано: «в заявленной сфере использования OS_Quesha, обеспечивается требуемый уровень сервиса в определённый промежуток времени». То есть OS_Quesha является системой реального времени для реализации торговли на фондовом рынке, исключая высокочастотную торговлю.
  Другое дело, что общие задержки на события фондового рынка при обычном использовании QUIK определяются следующими формулами:
1) <Общая задержка получения данных> = <Подготовка данных на бирже> + <Передача брокеру> + <Обработка брокером> + <Передача данных пользователю> + <Обработка данных в QUIUK и запуск колбенов> + <Реакция в пользовательской программе на колбеки>;
2) < Общая задержка выдачи пользовательских команд > = < Обработка в пользовательской программе полученных данных >+ <Передача команд в QUIUK >  + <Обработка команд в QUIUK > + <Передача брокеру> + <Обработка брокером> + <Передача команд пользователя брокером на биржу> + <Выполнение команд пользователя биржей>.
 Понятно, что задержка <Реакции в пользовательской программе на колбеки> на фоне остальных составляющих <Общей задержки получения данных> может быть для многих пользователей не сильно критической, но все равно лучше, если эта задержка будет маленькой.

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

  1. Дайте определение риалтаймовости торговых роботов.

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

После более 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 обеспечен контроль утечки памяти, блокировок и зацикливаний потоков, а также состояния очередей взаимодействия П/П).

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

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


И сколько вы готовы заплатить за это полезное   ? Если меня нанимать, то я запрошу большие деньги.

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

1. Более 20 суток не проявляются ошибки синхронизации (смотрите историю исправления этой ошибки в этой ветке) реализации многопотоковости QLua (обусловленной реализо-ванной  разработчиками QUIK архитектуры обработки колбеков). Это, совершенно не значит, что нет ошибок в API взаимодействия скриптов пользователя с QUIK.
2. Есть  предложения, по которым мы ждем ответа от поддержки (их пока два, как я думаю полезных):
1) предложение по исправлению критической ситуации (зависания QUIK на длинных фрагментов байт-кодов «чистых» Lua, без обращения к C-функциям);
2) предложение (не устраняющего критической ситуации, но обеспечивающее эффективность выполнения длинных фрагментов кода QLua с частым обращением к «коротким» C-функциям).
3. Приходится наблюдать интенсивные обсуждения проблем обработки колбеков.
   Есть, как мне кажется, хороший документ разработчика QUIK: «Использование Lua в Ра-бочем месте QUIK.pdf». Наверное, его можно было написать лучше, но даже, в том виде, как он есть, если тот, кто его внимательно прочитает и поймет, может избавиться от многих проблем обработки колбеков.

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

  Может быть вам подойдет следующий вариант.
  Вы оформляете функцию создания таблицы QUIK в виде отдельного файла. Далее загружаете этот файл с помощью loadfile  в нужный свой скрипт и в нужном месте запускаете байт-код, полученный в loadfile, для создания таблицы QUIK. Это можно делать на любом рабочем месте.

  Я не стал писать это сразу (извините, было некогда), но так как вам так сильно хочется приколов, что вы это особо отметили в вашем тексте, то пожалуйста.
  Вы внимательно прочитайте данную ветку, начиная со своего комментария № 88, и попытайтесь угадать с трех раз   . Кто, я или вы жаждет (и получает) грязи?
  Вы что, все-таки ловите в этом кайф?

Мой предыдущий комментарий это ответ swerg.

Вы меня здесь упомянули всуе, наверное,  для того, чтобы я вам напомнил наш с вами диалог (кстати, по теме данной ветки)   .
Ссылка:  https://forum.quik.ru/messages/forum10/message51063/topic6053/#message51063

  Согласен.  Интерфейс должен быть полным, обеспечивающим все необходимые операции пользователя, но максимально простым и ясным. Он должен минимизировать ошибки пользователя и облегчать сопровождение QUIK разработчиком.

Здравствуйте Старатель!

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

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

  Спасибо за ответ. Наверное, результат анализа будет интересен многим, читающим эту тему.

 Оба предложения собраны в одно (смотрите комментарий № 50). Просьба сообщить, принято ли данное обращение в работу, а также приблизительные сроки ответа.

  Да.
Но, основной поток QUIK, обслуживающий колбеки и таблицы QUIK (это не таблицы Lua) один. Если он блокируется в каком-либо скрипте, то перестает обслуживать остальные скрипты.

  Вы что, шуток не понимаете?  

 Все-таки, вы, неугомонные   . Что вас «гложет» так, что вы снова и снова жаждете продолжения  шоу, которое мы с вами устроили здесь и которое, наверное, поднадоело всем, в том числе, и мне? Вы, наверное, могли бы, вместо чтения  и писания в «рандомной» ветке, почитать официальную информацию, которой вы так доверяете (например, инструкции пользователя) на сайте производителя   . А если вы их уже изучили, то почитать какие-нибудь официальные, полезные для вас, книги по IT. Но вы же читаете и пишите в этой ветке. Какие-то вы уж очень противоречивые   .

  Здравствуйте!
В комментарии 50 собраны оба предложения. Просьба их рассмотреть.
Если у вас будут вопросы, то постараюсь на них ответить.

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

  Вы верите всему, что читаете?

 В той ссылки, которую вы указали используется QUIK v.8.13.0.106, Lua 5.4.  Ошибка синхронизации, устранена в версии QUIK v.8.13.1.16 (смотрите файловый архив на сайте разработчика). Надо обращать внимание на номер версии. Наверное, не все ситуации, которые возникают в QUIK 8.5. возникают, например в QUIK v.8.13.0.106

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

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