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

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

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

 Если заменить в выше написанном «реалтаймовость» на высокочастотность (смотрите ее описание в сети) , то,  с написанным, я, в основном, согласен.
  Однако, если обсуждать не стратегии торговли, а средства их реализации, то такие средства должны обеспечивать достаточно быструю реакцию на события, происходящие на фондовом рынке. Конкретно, в экспериментах (с включенным мусорщиком 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

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

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

 Это значит исключить эти операции из возможности помещать их в особый список. А далее смотрите мой текст. Хуже, чем сейчас не будет, если написанное будет реализовано корректно.

Текст данного комментария со Старателем не согласован, но надеюсь, что если, по его мнению, я написал что-то не то, он меня поправит.
---------
  Предложение1 (от Старателя).
     Мое краткое описание ситуации, устраняемое при реализации предложения Старателя, а далее цитаты.
     Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением  длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова других C-функций.
----
   Далее цитирую Старателя:
«Если цикл продолжительный, чтобы не было зависаний, можно вставить внутрь цикла любую с-функцию (не обязательно sleep). Причём, вставлять можно не на каждую итерацию, а через задан-ное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить ско-рость вычислений байткода в циклах.».
---
 Далее цитирую себя:
Комментарий 1.
«То, что предлагает Старатель, наверное, имеет смысл реализовать в самом QLua.
 Это примерно следующее:
1. Добавить в State поле счетчик.
2. При создании State  счетчик = 0.
3. В цикле работы виртуальной машины Lua (исходник Lua 5.3.5 lvm.c)
    после текста:
       Instruction i;
       StkId ra;

   добавить:
   if (++L-> счетчик  > !00)  {   //  100  это конечно же надо задать константой  --
    L-> счетчик = 0;
    lua_unlock(L); lua_lock(L);
   }»
---
Комментарий 2.
« То, что вы предлагаете (это обращение к Старателю), я сделал (в соответствии с тем, как описал в предыдущем моем комментарии) и проверил на своем стенде.
При "количестве циклов" = 1000 обеспечивается высокая скорость выполнения байт-кода и нет зависания.
 Ваше предложение легко реализуемо в QLua.»
--------------------------------------------------------------

Предложение2 (от TGB). Об оптимизации синхронизации в QLua.
  Не затрагивая существующей архитектуры обработки колбеков в QUIK, можно оптимизировать синхронизацию многопоточности QLua.
  Дело в том, что при синхронизации по умолчанию, как это, похоже, реализовано в существующей QLua, все вызовы C-функций имеют следующий общий вид:
unlock ….;
<Вызов C-функции>;
lock ……;
 В операциях unlock и lock возможны переключения потоков. То есть, это ресурсоемкие операции.  Если вызываемая C-функция выполняется быстро, как напри-мер, многие математические функции, то при существующей синхронизации, коэффициент полезного использования времени ЦП может быть очень низким :
<Время выполнения C-функция > / (< Время выполнения unlock >  + < Время выполнения  lock >).
Понятно, что в циклах QLua с обращением к коротким C-функциям QLua занимается в основном синхронизацией.
Идея оптимизации состоит в том, чтобы у пользователя была динамическая возможность задания/отмены C-функций, которые вызываются без выше описанной синхронизации (ввести особый список). Сделать эффективную  реализацию выше описанного несложно.
 Чтобы гарантировать обязательную «щель» для запуска колбеков, из списка допустимых C-функций, описанных в предыдущем абзаце операций, имеет смысл исключить sleep, а возможно, и еще какие-то функции обеспечения  задержек по времени и файловые операции.
 Существенным положительным моментом описанной оптимизации является то, что она никак не затрагивает тех пользователей, которые не будут ее использовать. При ее применении, коэффициент полезного использования времени ЦП:
1) для функций из особого списка: <Время выполнения C-функция > / < Время анализа особого списка>  
2) для обычных функций: <Время выполнения C-функция > / (< Время анализа особого списка> + < Время выполнения unlock >  + < Время выполнения  lock> ).
  При качественной реализации оптимизации можно добиться того, чтобы < Время анализа особо-го списка> было существенно меньше, чем (< Время выполнения unlock >  + < Время выполнения  lock>).
--------

   Предложение1 и Предложение2 совместимы при их совместной реализации, если реализация Предложения1 будет похожа на то, написано в Комментарий 1.    
    Предложение1 устраняет критическую ситуацию. Кроме того его реализация проста. Поэтому Предложение1 имеет смысл реализовать в первую очередь.

Есть два предложения по улучшению QLua.

   Первое по важности это, как мне представляется, ценное предложение Старателя по устранению критической ситуации «подвисания» скриптов на длинных участках чистого Lua (без вызова C-функций). Ссылка на его комментарий:  здесь
  Ниже его комментария есть два моих комментария о том, как это можно просто реализовать в QLua.
-----
  Второе предложение мое (ссылка на комментарий: здесь).
В нем описывается вариант повышения эффективности выполнения в скриптах длинных участков с частым обращениям к коротким C-функциям.
------

  Хотелось бы увидеть реакцию поддержки на эти два предложения.

  То, что вы предлагаете, я сделал (в соответствии с тем, как описал в предыдущем моем комментарии) и проверил на своем стенде.
При "количестве циклов" = 1000 обеспечивается высокая скорость выполнения байт-кода и нет зависания.
  Ваше предложение легко реализуемо в QLua.

 То, что предлагает Старатель, наверное, имеет смысл реализовать в самом QLua.
  Это примерно следующее:
 1. Добавить в State поле счетчик.
 2. При создании State  счетчик = 0.
 3. В цикле работы виртуальной машины Lua (исходник Lua 5.3.5 lvm.c)
     после текста:
        Instruction i;
        StkId ra;

    добавить:
    if (++L-> счетчик  > !00)  {   //  100  это конечно же надо задать константой  --
     L-> счетчик = 0;
     lua_unlock(L); lua_lock(L);
    }

После того как в QUIK 8.13.0.106 (с последними его исправлениями) синхронизация в QLua стала работать корректно (историю исправления можно посмотреть в ветке  "Отладка QUIK 8.13" ), стабильность OS_Quesha, при работе в этой версии QUIK, стала такой же, как в старых версиях (до версии 8.5).

 Не согласен, я Атема ни разу не обозвал грязными словами. Но, думаю, что от этого ему не сильно легче.

 Это все на что способен этот не уважаемый  

 Я хотел это оставить на потом, но исходя из того. что, похоже на то. что вы не исправимы:
  1) вы не плохо разбираетесь в языке программирования Lua (это ваш плюс);
  2) у вас много комплексов; и главный комплекс это проблема самодостаточности. когда вам хочется кого то унизить (но вы зря думаете. что я это подходящий объект0.

 Вы сами, понимаете, что написали?  Все таки вы упорный. Зачем вы нарыватесь?

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

 Меня не интересуют классические имплементации. С этим разбирайтесь вы.

 Букв слишком много.

 Очень много букв  
 Если о моем стиле "идеального стиля общения", то всего два пункта:
 1) Не обижай тех, кто готов с тобой конструктивно взаимодействовать.
 2) Не пропускай хамства, тех. кто на этом думает на этом по пиарится.

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

 Владимир, вы себя ведете на форуме очень грубо. Ангелов на форуме нет (это я отношу и к себе), но вы выделяетесь. Все таки мы находимся не в подворотне. На выподы против вас можно отвечать и по интеллигентнее.

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

  Все sleep, запускаемые в main, с любыми интервалами, будут выполняться последовательно. И мне стало интересно, что вы понимаете под прерыванием по таймеру (надеюсь это не аппаратные прерывания:smile: ). Поэтому, с этого места, пожалуйста, опишите поподробнее. Тела ваших циклов меня не интересуют, но схему их организации вы, наверное, смогли бы привести.

Тест синхронизации в QUIK 8.13.0.106 после 13.04.21 (с последними его исправлениями) до сих пор не "падает". Для меня это означает, что в этой версии QUIK синхронизация в QLua реализована корректно.

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

Наверное, стоит пояснить, что же представляет собой контекст выполнения функции. Это все, от чего зависит ее результат.  А это, в некоторых случаях не только явно задаваемые ее параметры, но и среда, в которой она выполняется. Например, результат файловой операции зависит не только от ее параметров, но и от состояния, в котором находится файл. Если не учитывать остальной контекст файловой операции, а только ее параметры, то можно бы было сказать, что эта операция неоднозначная (при одних и тех же параметра результат может быть разным). При учете всего контекста файловая операция однозначная.
 Если бы вы работали без операционной системы (ОС), то в контекст выполнения ваших функций входило бы и все то, чем занимается ОС (прерывания, параллельно работающие ядра ЦП и т.д). На самом деле, корректно реализованные средства разработки программ, в том числе и  QLua, локализуют (уменьшают) тот контекст, от которого зависят пользовательские функции.
 В QLua, в той реализации как он сейчас есть и в том виде как его используют большинство пользователи (main и колбеки), по существу является однопоточным. А если это так, то, при корректной реализации QLua, проблемами параллелизма (в том числе атомарностью) можно было бы не озадачиваться.