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

   Я повторю (так так текст достаточно короткий) то, что мною было написано 10.06.2021 12:57:14.
             Об областях синхронизации.
 Область синхронизации программы это та часть области видимости переменных программы, для которых предполагается обеспечить атомарность (! всей совокупности этих переменных как единого целого) при многопоточной обработки данных.
 Распространенной ошибкой синхронизации в параллельном программировании является непра-вильное определение области синхронизации. Для эффективности синхронизации ее область должна быть минимальнонеобходимой (однозначно определяющей результат программы), обеспечивающей корректность работы программы. Если область синхронизации программы содержит в себе минимальнонеобходимую, то все будет работать корректно (но, возможно, не вполне эффективно). Если же область синхронизации не включает в себя минимальноне-обходимую, то это ошибка программы. Поэтому при разработках, в тех случаях, когда не очевидна минимальнонеобходимая область синхронизации, обычно первоначально область синхронизации выбирается с «запасом». Далее эта область, в процессе развития проекта, может быть «сужена», с целью повышения эффективности синхронизации, до минимальнонеобходимой.
-----
И  10.06.2021 13:59:1.
 Возможно, то, что написано далее, разработчики QUIK хорошо понимают, но на всякий случай некоторые соображения.
   В рабочем месте QUIK объекты синхронизации функций API QLua должны локализоваться в месте, общем для всех скриптов пользователя, и это место точно не global_State и тем более не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов QUIK массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией. Синхронизация должна выполняться не только при обращении к функциям API, но в соответствующих программах, готовящих данные для обсуждаемых функций в потоках отличных от пользовательских.
---------
   На самом деле, достаточно показать, разницу по времени выполнения в разных версиях QUIK и, как я понимаю, пользователями в этой ветке сделано.  Для разработчиков QUIK этого должно быть достаточно.

      Упомянутый код демонстрирует проблему в QUIK 9.3.1.11. В QUIK 9.3.3.3 QLua 5.4 эта конкретная проблема устранена. Но, возможно? ,  в QUIK 9.3.3.3 была изменена схема синхронизации в функциях API  QLua (на форуме можно найти много нареканий на ошибки работы некоторых из них, связанных, скорее всего, именно с ошибками синхронизации).
    Существует проблема использования нескольких скриптов в одном рабочем месте QUIK. Это связано с тем, что поток, обслуживающий все колбеки (фондового рынка и таблиц QUIK) один (блокировка в котором блокирует все скрипты рабочего места) и, если в колбеках, есть обращение к функциям API QLua, то все запущенные скрипты рабочего места QUIK, могут выстраиваться в очередь к синхронизуемым ресурсам QUIK (по которым в ранних версиях QUIK, возможно синхронизации вообще не было), что эквивалентно их работе в одном потоке. Если выше написанное имеет место, то решением может быть следующее: между потоком обслуживания колбеков и потоками main в скриптах создаются очереди, в которые записываются только параметры, обрабатываемые в main. Это делается просто, но можно использовать и готовый модуль, код которого приведен по ссылке: https://quikluacsharp.ru/stati-uchastnikov/modul-realizatsii-interfejsa-obrabotki-sobytij-quik-s-ispolzovaniem-ocheredej-sobytij/

 Ну тогда "хлебайте" то, что вам предлагают и не жалуйтесь на новые версии QUIK (вы же в них не работаете).

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

   Я думал что вы бесстрашный  
   Вы же можете оставаться на "любимых" вами версиях (даже на QUIK 7....) достаточно долго (минимум, лет 5). Какие у вас проблемы?

  А что же вы боретесь с новыми версиями?  

  А почему бы вам не вернуться на исконно-посконную версию QUiK 8.5, которая, как я понимаю, с вашей точки зрения, более стабильная?

  У вас такой печальный опыт. У меня была счастливая возможность наблюдать, а иногда и участвовать в том, как качество программ программ, со временем, улучшалось.
  Надеюсь что и вам, если вы будете переходить на новые версии QUIK, выпадет (через год?) такое счастье   . А чтобы ощутить это сейчас, вы могли бы перейти на QUiK 8.5, а потом вернуться на версию, которую используете сейчас.

  Декларация вашего мнения в данной ситуации не очень существенна. Оно уже многократно вами озвучено и старо как этот мир: не пущать    Но жизнь не остановить. Будут новые версии QUIK. Будут в нем ошибки и исправления. Странно то, что вы с этим продолжаете безнадежно бороться. Вы что, жизни не видели?

 Без учета эффекта Доппера и спина электрона  ваше объяснение не канает  

 Это вы под ником nikolz комментарии пишите?  

   Ну и как вы объясните 16-ти кратную разницу времени выполнения скрипта ?:
1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше)
    -----

Вам не лень всякий раз цитировать комментарии пользователей полностью?
Не можете удержаться перед халявой?
Вы же так можете разорить АРКУ на накопителях базы форума  

1.  Я бы на месте АРКИ зачислил вас в нештатные сотрудники  
---
2. Конечно, при разработке скриптов желательно чтобы они были (выполняя свои функции) как можно проще и допускали простоту последующей модификации.
    Рыночная эффективность торговой стратегии (ее доходность на определенном перио-де) может не сильно коррелировать с ее сложностью. Поэтому при разработке скрипта имеет смысл начинать с простых стратегий, не требующих много данных и вычислений и только потом добавлять учет дополнительных факторов поведения рынка.
    QUIK не то место, в котором надо заниматься событийным программированием, существенно усложняющим скрипты. Колбеки следует использовать по минимуму. Лучше от-слеживать доступные в QLua состояния рынка, а также состояния выполнения заявок. Заявки лучше использовать только лимитированные, иначе будут возникать рыночные по неконтролируемым ценам. Все сложные заявки системы: со стопами, тейки, айзберги и т.д., если вдруг они требуются, лучше реализовать в самом скрипте с использованием комбинаций лимитированных заявок. Собственные сложные заявки, будут выполняться с некоторой задержкой по времени (по сравнению с системными), во многом определяемой качеством канала связи с вашим брокером, но за это вы будете иметь более полный контроль над ними.  
----
3.  Во втором пункте я написал, что скрипты желательно создавать простыми, Но это вовсе не означает, что инструмент для их создания должен быть «корявым». И когда после очередного изменения QUIK, создание таблиц в OLua начинает выполняться в 16 раз дольше, чем до изменения, то это оскорбляет «мои эстетические чуства»   . Вы понимаете, что в QLua фактически единственный тип это таблица с индексами/ключами и полями (известных типов)?  Замедление в 16 раз это аномальное поведение QLua, с которым должны были разобраться разработчики QUIK. Что они и сделали, выпустив версию QUIK 9.3.3.3, в которой этого замедления нет. Это не значит, что в этой версии нет проблем, о которых написали другие пользователи (это надо проверять). То, что в QUIK возникают и исправляются ошибки это нормально. Главное это чтобы исправленных было больше чем возникших. Плохо то, что поддержка не дает четкого объяснения возникающих ситуаций.
----
  Для того чтобы не разбираться с новыми глюками новых версий QUIK, у вас есть воз-можность выбрать существующую версию с «любимыми» вами глюками  и оставаться на ней столько, сколько вам захочется.

 Предложение почти гениальное, особенно с учетом того, что обуждается проблема производительности скриптов в QUIK  
 У вас нет понимания, что при встраивании Lua в QUIK его разработчиком вносятся изменения, которые способны изменить встроенного Lua?

  Переведите все в терасекунды и вам все станет понятнее  

  Спасибо. А то я этого не знал  

   Вы какую версию QUIK используете?
  Задавая вопрсы надо обязательно указывать версию.

  Вы поняли неправильно.  Задача одна и та же. Версии QUIK разные.
 Читайте:

  Тест комментария 55 в QUIK 9.3.3.3 (QLua 5.4) выполняется столько же как и в QUIK 8.13.1.16 (QLua 5.4)

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

  А того, что некоторые пользователи достаточно активно используют таблицы Lua (это относится и ко мне) и все, что связано с созданием таблиц, в QUIK 9.3.1.11 (QLua 5.4) выполняется в 16,25 раз дольше чем в QUIK 8.13.1.16 (QLua 5.4).  Это влезли в ваш ПК и снизили его производительность в 16 раз.
   Я не понял, что вы так заботитесь о том, чтобы разработчик QUIK не устранял глюки?
   Если у вас все хорошо, зачем вы мешаете другим пользователям решать свои (а может быть и ваши) проблемы?

  Я бы папуасам не рискнул объяснять, что такое тензорное исчисление, но у меня есть надежда, что поддержка не папуасы
----
 Вообще то, новые версии QLua у разработчика QUIK должны проходить хотя бы простейшие тесты.
  Например, без подключения к серверу:
1) проверка подключения пакетов;
2) проверка скорости выполнения циклических операций;
3) проверка работа таблиц:
-  скорости создания таблиц;
-  скорости доступа к элементов
И так далее ……
----
 Неужели этого у разработчика QUIK до сих пор нет таких тестов?

Имеется ввиду строка:        for i = 1, N do hour = {} end

В ниже приведенном коде выделена строка символами ###, которая в QUIK 9.3.1.11 (QLua 5.4) выполняется в 16,25 раз дольше чем в QUIK 8.13.1.16 (QLua 5.4)
 Где поддержка??

Присоеденяюсь.
-----
 Деградация эффективности QLua показатель низкого качества реализации разработчиками QUIK встраивания Lua в QUIK. Эффективность выполнения скриптов QLua без обращения к API QUIK должна отличаться от Lua только затратами на операции lock/unlock в вызовах функций C-API QLua, а также в VM-QLua (ulock/lock) при вызове C-функций. Причем упомянутые операции в подавляющих случаях «холостые» (потоки не переключают). Все места вызова lock/unlock (ulock/lock) определены в кодах Lua разработчиком Lua.  Разработчику QUIK достаточно корректно реализовать lock/unlock, например, используя критические секции, обеспечивающие эффективную синхронизацию.
   Вопрос к поддержке: какое «ноу-хау» обеспечивает деградацию эффективности QLua новых версий?
-----
 Интересное открытие (пишу без иронии).
 Вопрос к поддержке: a это зачем сделали?  Хотелось бы чтобы разработчик QUIK пояснил как додумался до этого. Какие проблемы это решает?

    Итак, в Qlua 5.4 есть «плавающая» ошибка (скорее всего ошибка синхронизации).
  ---  
  «Простой» тест, диагностирующий некорректную обработку колбеков в QLua 5.3, появился у меня в результате анализа «мерцающей» ошибки в скрипте, похожей на ошибки в QLua 5.4, описанные Старателем, когда в переменной сразу после присвоения ей значения, это значение на следующем шаге оказывалось искаженным. Нельзя исключать, что природа ошибок, обнаруженных Старателем и мною одна и та же.
  Притом, что обсуждаемый тест ошибку в QLua 5.4 не показывает на коротком интервале времени, это совсем не значит, что такой ошибки в QLua 5.4 нет. Дело в том, что проявление ошибок синхронизации по времени может сильно зависеть и от того какая версия QLua используется. Я могу ошибаться, но, скорее всего, схемы синхронизации потоков в QLua 5.3 и в QLua 5.4 аналогичны. Поэтому, если бы разработчик QUIK, нашел бы ошибку в QLua 5.3, то он бы, наверное, нашел бы ее и в QLua 5.4. Обсуждаемый тест воспроизводит ошибку (в описанных мною условиях) в QLua 5.3 в интервале 2-3 мин. с локализацией места с точностью одной строки кода.

Пакеты для Lua 5.4:  https://cloud.mail.ru/public/YCHN/jFfkrPLBq
iup,  lfs, sqlite3
Lua - файлы для сборки пакетов под Lua 5.4.

Появилась очередная версия QUIK 9.3.1.11. В этой версии проблема существует.

  Здравствуйте.
Действительно, обсуждаемую ошибку в QLua 5.4 я не наблюдал. Но, если разработчик QUIK поддерживает и QLua 5.3, то, наверное, надо эту ошибку устранить и в QLua 5.3. Тем более, что эта ошибка базовой функциональности обработки колбеков.
 Причем, тест https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500 , диагностирующий ошибку мною упрощен до такой степени, что проявление ошибки в коде теста локализовано в пределах одной строки, помеченной комментарием --- ###.  Этот тест разработчик может использовать при поиске ошибки в QLua. Просьба передать его коды и описание ошибки в комментарии https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872 разработчику QUIK.

 И пусть разбираются разработчики QUIK.

Согласен.

  Я так и не понял, зачем вы анализировали замыкание функций в пустом цикле:

 Добавлю к приведенному выше коду:   и не должно быть при корректной реализации многопоточного использования Lua.

   В предыдущем моем комментарии у меня не было времени подробно пояснить, что понимается под схемой использования Lua во многих потоках. Попробую это сделать сейчас.
   Главный thread  и остальные thread Lua пространственно, по стеку, разделены и поэтому могли бы обрабатываться в разных потоках без синхронизации. Но не допустима обработка любого thread в нескольких потоках. Если в разных thread нет общих модифицируемых данных, то синхронизация между thread не требовалась бы. Казалось бы, thread могли бы работать параллельно, синхронизируясь только на общих модифицируемых данных. Однако, в Lua есть «общее хозяйство» всех thread , требующее синхронизацию – это общая автоматическая память Lua, поддерживаемая мусорщиком, «заточенным» разработчиками Lua только на однопоточное использование. Поэтому VM-Lua можно использовать в разных потоках только в разделяемом режиме. В любой момент времени VM-Lua может обрабатывать только один поток.

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

  Здравствуйте.
 Действительно, обсуждаемую ошибку в QLua 5.4 я не наблюдал. Но, если разработчик QUIK поддерживает и QLua 5.3, то, наверное, надо эту ошибку устранить и в QLua 5.3. Тем более, что эта ошибка базовой функциональности обработки колбеков.
  Причем, тест https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500 , диагностирующий ошибку мною упрощен до такой степени, что проявление ошибки в коде теста локализовано в пределах одной строки, помеченной комментарием --- ###.

Я поддерживаю поддержку QUIK в стремлении навести порядок на форуме. Здесь не подворотня. «Стычки» между пользователями, конечно, допустимы (в профессиональных рамках), но без перехода на личности. Как мне представляется, «грязный» спам, не имеющий отношение к обсуждаемой теме, поддержка может удалять исходя из своих представлений без объяснения своих мотивов. Миндальничать, наверное, не надо.

Да

Тест, описанный в комментарии (10.09.2021) https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872  упростился (строка с проблемным кодом помечена символом ###):

 Согласен.  luaL_setfuncs не применима к функциям Lua, а только к С-функциям.
---
 Эксперименты показали, что проблема в lua_pcall (нет блокировки доступа к байт-кодам). Либо в этой функции нет синхронизации в QLua 5.3 (что очень сомнительно), либо в ней не корректно указана ссылка на объект синхронизации (он должен быть общим для всех lua_State скрипта).

   Вообще, мне (и остальным пользователям QUIK) не интересны причины наблюдаемой ошибки. Нам существенно, чтобы эта ошибка была устранена.

   Долго изучаете проблему.
 Не точно, но скорее всего, колбеки регистрируются в QLua (а этого можно и не делать - смотрите мои комментарии) с помощью функции: void luaL_setfuncs (lua_State *L, const luaL_Reg *l, int nup) и, наверное, с параметром nup = 0. Параметр nup = 0 означает, что это C - функции и они запускаются без блокировки байт-кодов. Что является ошибкой.
----
 Возможно, я ошибаюсь, и все-таки просьба к поддержке: донести этот комментарий до разработчиков QUIK.

Зачем смуту сеете в «неокрепшие» умы   ?
---
 Даже если ядро одно, то все равно может сброситься. Потоки и при одном ядре переключаются по времени из-за выделения им квантов процессорного времени. Переключение на выполнение потока колбека может случиться сразу после проверки в main: os.time ()  >  Time. И тогда Time может сброситься при выполнении колбека.

    Здравствуйте!
    Появилась версия QUIK 9.2.2.11 (с обновлениями).   В этой версии в QLua 5.3 тест, описанный в комментарии (10.09.2021) https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872  демонстрирует ошибку в запусках колбеков. Эта ошибка может проявляться как случайные сбои в сриптах пользователей в различные моменты времени.  В версии в QLua 5.4 ошибка не проявляется
    У поддержки есть вопросы по тесту?

1. nikolz зачем при ссылке на мой код процитировали его весь? Он все-таки длинный и достаточно было бы привести несколько строк. У вас что, есть план по объему генерации текстов своих комментариев   ?
2. Это
вы написали не случайно   ? А если так, то можно предположить, что это разрешение вашего гипотетического таймера, который вы собираетесь создать (готового пока у вас я не вижу ничего) используя
Разрешение таймера в 0.1 мкс в Windows (только не путайте с возможностью засечки времени в Windows с использованием QueryPerformanceCounter) было бы круто не только для QLua, но и для C. Я, правда, не очень понимаю, зачем такое разрешение нужно в QLua, но ваша заява так впечатляет и претендует на открытие, что мне стало интересно, а вдруг вы Кулибин от программирования   .
   Вам известно, что интервалы в WaitForMultipleObjects можно задать только в млсек.?  Вообще, расскажите подробно в деталях, что вам известно о WaitForMultipleObjects (возможно, неизвестное мне), позволяющее, по-вашему, мнению, использовать эту функцию для обеспечения разрешения вашего гипотетического таймера в 0.1 мкс. Только не рассказывайте, это на «растопыренных»  пальцах, а приведите нормальное API и к нему нормальный код (лучше, ваш, работающий, или хотя бы, найденный в сети) на каком-нибудь, известном вам языке программирования. Я попытаюсь такой код понять и как то его прокомментировать.

И это весь ваш (очень простой   ) работающий код, который я могу запустить на своем ПК с тем, чтобы проверить, как он замечательно работает?
--
 Ну, если бы приведенный вами «код» работал бы, то это было бы, конечно, большое достижение, особенно с учетом того, что все исполняемые приложения контролируются ОС   .

По ссылке https://cloud.mail.ru/public/ts3g/4PJofyayZ   расположены коды для работы из QLua (5.3,  5.4) c базами SQLite.
   !! Файл  sqlite3.dll одинаковый для 5.3 и 5.4.
Простой вариант подключения к пакету:
1) Переслать файлы варианта 5.3, либо 5.4 в папку с info.exe
2) В скрипте подключиться к пакету следующим образом

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

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

1.
 Ну. про это я, наверное, знаю.
А вы попробуйте привести здесь свой работающий код и тогда поговорим.

2.  Тот кто соображает, поймет, что выложенный мною модуль обеспечивает возможность запускать пользователю свои функции в отдельном (от основного потока QUIK) потоке.

Извините не заметил искажения автора цитаты. В предыдущем комментарии цитата Старателя

Нужно ли переносить функциональность скрипта в основной поток с учетом написанного мною в предыдущем комментарии, а также с учетом цитируемого ниже?
   Ответ разработчика QUIK (документ «Использование Lua в Рабочем месте QUIK»):
«При использовании событийной модели Lua скрипт выполняется в двух потоках: функции обратного вызова выполняются в основном потоке РМ QUIK, а функция main() в до-полнительном потоке РМ QUIK (подробнее см. п. 1). При этом для предотвращения «подвисаний» РМ QUIK необходимо каким-либо образом оптимизировать сценарии, описан-ные в функциях обратного вызова. Одним из способов такой оптимизации является перенос логики обработки полученных сигналов в функцию main(). Данный подход сводит количество сценариев в функции обратного вызова до одного, а именно добавление в глобальную Lua таблицу (очередь) записи о том, что функция сработала и вернула определённые значения. Таким образом, мы получаем очередь событий, которые необходимо обработать в другом потоке.»
-----
  Если кому интересно, то в моем комментарии https://forum.quik.ru/messages/forum10/message57686/topic6198/#message57686
выложен код реализации модуля обработки событий колбеков и событий таблиц QUIK с использованием очередей.  Там же приведен скрипт-шаблон подключения модуля и при-мер его использования.
 При использовании очередей проблем синхронизации нет вообще. Основной поток выполняет по событиям QUIK только короткие записи параметров колбеков в очереди, которые обрабатываются в потоке main.

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

  То есть, для вас чем меньше ядер у ПК, тем лучше?