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

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

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

Текст данного комментария со Старателем не согласован, но надеюсь, что если, по его мнению, я написал что-то не то, он меня поправит.
---------
  Предложение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" )?

 Ну вы консерватор
 Регрес действительно временами (часто) наблюдается, но в основном, все-таки по принципу один шаг назад, а два вперед.
 Я понимаю, что вы сами с усами  И все-таки, я бы на вашем месте перешел на QUIK 8.13.0.106 и еще бы сделал его обновление последними исправлениями.

 Вы в кокой версии QUIK работает?
Я написал:

Поддержка в ветке так и не проявилась.
  Но есть и хорошая новость. Тест (это OS_Quesha, запущенная в особо тяжелом режиме тестирования синхронизации в 16 потоках) в обновленном QUIK нормально работает до сих пор (16.04.21   15.28). Никаких аномалий типа утечки памяти, зацикливания и т.д. я в QUIK не обнаружил. Мои попытки «обрушить» QUIK многократными дополнительными запусками из OS_Quesha скрипта в котором есть файловые операции, отладочные операции, операции сереализации и восстановления таблиц, в том числе и _G, не удались. Для меня это означает, что в обновленном 13.04.21  QUIK 8.13.0.106 синхронизация в QLua, наконец, реализована корректно и QUIK, я думаю, стал более стабильным. Похоже, эта эпопея , начавшаяся для меня в мае 2020г. с посылки поддержке первого письма с дампом и с текстом о том, что в QLua 8.5 есть ошибка синхронизации, завершилась.

   Чем меньше дергаешься, тем реже падаешь
   Я не ставлю задачу что-то моделировать. Первая задача при разработке любой программы это обеспечение правильности ее работы.
   В своих разработках программ придерживаюсь некоторых принципов.
Вот два из этого списка:
1) Не делай лишней работы.
2) Все, что можно реализуй статически.
-----
  Если по существу обсуждаемого, то я жду субботы. Если мой тест, запущенный в обновленном QUIK 8.13.0.106, не уронит его до субботы, то для меня это будет признак того, что в обновленном QUIK обсуждаемая синхронизация, скорее всего, наконец, реализована корректно.

 
 После упомянутого мною обновления QUIK 8.13.0.106,  скорости  на «смешанном» коде Lua (с обращениями к С-коду) в QUIK и на моем стенде сравнялись. Для меня это косвенный признак того, что, в обновленном QUIK 8.13.0.106 синхронизация могла быть реализована, как на моем стенде, то есть, по моему мнению, правильно. Для подтверждения этой гипотезы я в новой версии QUIK запустил 13.04.21 вечером свой тест, который не обновленную версию QUIK "ронял" гарантированно в пределах чуть более одних суток. Сейчас 15.04.21  17.56 тест идет нормально и установлен новый продолжительности его работы. При этом, в обновленном  QUIK 8.13.0.106 я не наблюдаю никаких проблем. Если тест не "уронит" QUIK до субботы, то, наверное, можно будет, с большим основанием, предположить, что в обновленном QUIK 8.13.0.106 наблюдаемые мною ранее ситуации устранены, то есть синхронизация реализована корректно.

  Тогда, за необоснованное подозрение, извините.

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

 Попробую объяснить.
 Дело в том, что при программировании на Lua вам совсем не надо управлять памятью (ее запросом/возвратом, контролем за всем этим - большой геморрой при разработке программ). В Lua это делается автоматически ("под капотом"). Тем не менее это все делается за счет вычислительных ресурсов пользователя (время ЦП, память и т.д.).
 Существуют ситуации, в которых вроде бы на безобидных операциях в циклах, например:    s = s .. s1 расход вычислительных ресурсов может резко увеличивается. На каждом выполнении  s = s .. s1 в невидимом для вас управлении памятью выполняется по меньшей мере запрос памяти под новый размер s и отказ от памяти s до начала операции. Запрос памяти это достаточно затратная операция, как-то зависящая от размера памяти. Для отказа от памяти в Lua, не считая некоторых случаев, ничего специально не выполняется.  Если на некоторую область памяти нет ссылок из существующих в текущий момент объектов скрипта, то она считается неиспользуемой (мусорной). Но чтобы мусор не накапливался (это никем не используемая память ПК), в Lua время от времени запускается сборка мусора (одна из наиболее сложных операций, выполняемых "под капотом" Lua). Сборка мусора тоже использует вычислительные ресурсы скрипта.

  Вы дали ответ только на два мои вопроса (а их всего четыре). Было бы интересно почитать ваши версии ответов на остальные мои два вопроса.
  Кстати, по поводу возможной оптимизации синхронизации в QLua, вы можете посмотреть мой комментарий в ветке «Средства разработки многопоточных скриптов в QUIK».

  Вы это пишите как разработчик QUIK или как любитель?
  Вы прочитали это?:
-----
  Могу так же поздравить себя с тем, что после упомянутого мною обновления QUIK 8.13.0.106  скорости  на «смешанном» коде Lua (с обращениями к С-коду) в QUIK и на моем стенде сравнялись. И куда же делась "затейливость", обеспечивающая высокую скорость QUIK?  
   Причем, в обновленном QUIK мой тест, запущенный вечером 13.04.21 пока работает без проблем. Если он не "обрушит" обновленную версию QUIK до субботы, то скорее всего он дотянет и до следующей субботы. А если это произойдет, то кому что-то будет непонятно?

  "Неожиданно для меня" это фигура речи. Конечно же, мною были нажаты все необходимые кнопки.

)

  Читать не читают, но что характерно :
  1. Мой комментарий был написан 10.04.21.
  2. А вчера вечером (13.04.21) мой QUIK 8.13.0.106 совершенно неожиданно для меня автоматически обновился.
   Возможно это простое совпадение, но на всякий случай я запустил в нем свой тест (с подключением к серверу. Если он не "обрушит" обновленную версию QUIK в течении недели (до 20.04.21) то, наверное, разработчиков QUIK можно будет поздравить. При этом я не исключаю, что действительно поддержка ветку не читает (и особенно, длинные тексты )

Поддержка эту ветку не читает?

Об оптимизации синхронизации в 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>).

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

  При сереализации не стоит задача получить строку в удобно читаемом формате.     Для этого есть функция dump_tbl, где выделяются все отступы и т.д.
Для  задачи сереализации достаточно того, чтобы результат str_to_tbl (<строка-результат из функции tbl_to_str (<Таблица>....) был <Таблица>.
 В принципе, не очень сложно, так модифицировать, выложенный мною модуль, чтобы формат сереализованной таблицы был в виде
 {  
      [] = {
                ........
              }
  }
 но это уже не принципиально и я не вижу смысла в том, чтобы этим заморачивться. Строка-результат сереализации предназначена не для изучения ее пользователем, а для подачи в функцию восстановления таблицы.

  Не согласен, как говорили в армии: "Хочешь выжить. Учи матчасть!"

  Замечание верное. Спасибо.
  Я не знал, что это работает быстро.

Увидел ошибку:
 Исправление:
if Level < (limit +2) or limit == 0 then

Новые версии QUIK стали заметно устойчивее, чем это было в мае 2020г.
Однако, нечасто, но в течении двух-трех суток версия QUIK 8.13, в которой запущен мой тест синхронизации в QLua, без подключения к серверу, зависает с выдачей сообщения: Critical error ACCESS_VIOLATION (Критическая ошибка НАРУШЕНИЕ ДОСТУПА). Дампы при этом не сбрасываются.
  Многое  указывает на то, что в QUIK 8.13 есть ошибка синхронизации (и все-таки земля вертится ).
  Попробую это обосновать.
1. Ошибка «error ACCESS_VIOLATION» в QUIK 8.13 возникает в разных местах моей тестовой программы, и в разные моменты времени.
2. Я собрал из исходников Lua 5.3.5 вариант исполняемого кода Lua (свой стенд), в котором допустимы обращения к VM-Lua из разных потоков. На этом стенде, точно та же моя тестовая программа (16 интенсивно нагруженных  потоков в одном Lua-скрипте), работает непрерывно неделями, и я не могу дождаться, когда же она, наконец, упадет.
3. Я провел следующий эксперимент:
1) Запустил  на выполнение программу на «чистом» Lua (без обращения к С-кодам, где отсутствует синхронизация) в QUIK 8.13 и на моем стенде. Время выполнения оказалось одинаковым.
2) Запустил  на выполнении программу на «смешанном» Lua (с обращениями к С-кодам, где должна работать синхронизация) в QUIK 8.13 и на моем стенде. Время выполнения оказалось разным. Причем на моем стенде ~ 1, 4 раза больше.
 Вопрос:  в QUIK 8.13 сумели, как то сильно оптимизировать синхронизацию доступа к VM-Lua из разных потоков?
Я думаю, это вряд ли. Скорее всего, есть ошибка в реализации синхронизации в QLua 8.13.

   В своем стенде, для синхронизации доступа к VM-Lua, я использую критическую секцию, и далее я приведу все места в исходном тексте Lua 5.3.5, где мною были внесены изменения для обеспечения синхронизации.
   Обращаю ваше внимание на то, что при синхронизации должен использоваться общий объект синхронизации. Возможно?, место синхронизации в QLua было выбрано неудачно.
-----
  Мои изменения (для обеспечения синхронизации) в исходном коде Lua 5.3.5 приведены в следующем виде:
1) № изменения
2) <Имя файла исходника>
3) <Текст исходника, позволяющий определить место после которого внесено изменение>
4) <Текст изменения>
--------------------------------------------------------------------------------
1. Изменение № 1
Файл:      ldo.c
Место:   #include "ldo.h"
Добавление:
  #include "DbgHelp.h"
#pragma comment(lib, "Dbghelp.lib")
void lua_lock_MT(lua_State *L) {
global_State *g = G(L);
EnterCriticalSection(&g->Глобальная_критическая_секция);  
}

void lua_unlock_MT(lua_State *L) {  
global_State *g = G(L);
LeaveCriticalSection(&g->Глобальная_критическая_секция);

}
------
2. Изменение № 2
Файл:      ldo.h
Место:   # LUAI_FUNC int luaD_rawrunprotected (lua_State *L, Pfunc f, void *ud);
Добавление:
  void lua_lock_MT(lua_State *L);
  void lua_unlock_MT(lua_State *L);
-----
3. Изменение № 3
Файл:      lua.h
Место:  LUA_API int (lua_gethookcount) (lua_State *L);
Добавление:
void lua_lock_MT(lua_State *L);  
void lua_unlock_MT(lua_State *L);  
------
4. Изменение № 4
Файл:      lua.h
Место:  #define lua_h
Добавление:
    #include "windows.h"  

4. Изменение № 4
Файл:      limits.h
Место:  
  /*
  ** macros that are executed whenever program enters the Lua core
  ** ('lua_lock') and leaves the core ('lua_unlock')
*/
Добавление:
  #if !defined(lua_lock)
    #define lua_lock(L) lua_lock_MT(L)      
    #define lua_unlock(L)   lua_unlock_MT(L)  
  #endif
-----
5. Изменение № 5
Файл:      luaconf.h
Место:  
** the libraries, you may want to use the following definition (define
** LUA_BUILD_AS_DLL to get it).
*/
Добавление:
#define LUA_BUILD_AS_DLL
-----
6. Изменение № 6
Файл:  lstate.c    
Место:
g->gcstepmul = LUAI_GCMUL;
Добавление:
InitializeCriticalSection(&g->Глобальная_критическая_секция);
-----
6. Изменение № 7
Файл:  lstate.h    
Место:
TString *strcache[STRCACHE_N][STRCACHE_M]; /* cache for strings in API */
Добавление:
   CRITICAL_SECTION Глобальная_критическая_секция;

-------------------------------------------------------------------

  Возможно, в чем-то я ошибаюсь и все-таки, большая просьба к поддержке: довести этот мой комментарий до разработчиков QUIK.