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

Обработка колбеков в 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, проблемами параллелизма (в том числе атомарностью) можно было бы не озадачиваться.

 Уточнение. Если скрипт  выполняется  без "падения".

1. Все операторы в QLua (включая функции, запускаемые в колбеках), в  том числе с участием атомарных C-функций (выдающих однозначный результат в контексте их запуска), являются атомарными.
2. Взаимодействие колбеков с main подробно обсуждалось в ветке «Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номе-рами заявок и сделок» и Антон там достаточно детально это описал.

 Фрагмент  if N >= 0 then N = N + 1 это "чистый" Lua, а при текущей реализации QLua все такие участки (и в мейне и в колбеках) выполняются под общей блокировкой. Поэтому это атомарная операция.

Итак, сегодня суббота.
"Уронить" QUIK 8.13.0.106 после 13.04.21 (с последними его исправлениями) мне не удалось. Ни с помощью моего трэшевого теста, ни добавлением к его работе частого запуска "тяжелого" скрипта с разнообразными операциями. Высказанные ранее мною предположения пока подтверждаются.

 У меня возникло ощущения, что вам нравится с этим кувыркаться

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

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

  Спасибо за ликвидацию Eddiewafа. а также за вашу реакцию на другие мои некоторые комментарии.

А что тут делает Eddiewaf ("КатСервис 56" )?