Потокобезопасные функции в Lua 5.3

QUIK 8.8.1.5
Можно запустить несколько копий, чтобы наверняка.

По всем признакам разрушение стека луа. Второй вариант попробовал, словил дамп со второй попытки перезаказа, access violation. Поковырял его, что мы видим

Скрытый текст

Курсор на момент падения находится в функции lua53!auxgetstr(). Сама эта функция из lua53 не экспортируется, что-то еще по пути компилятор выбросил при оптимизации, видимо. Прошел по колстеку вверх, не нашел, чтобы где-то был лок захвачен перед вызовом, а сама функция, как внутренняя для луа, его не захватывает. Оно ничего не значит, конечно, не нашел и не захвачен разные вещи, накидываю как идею для арки, куда посмотреть.

Еще раз поправлюсь. Падает на lua_getglobal. В qlua.dll основным потоком квика вызывается некая функция, она пытается вызвать lua_getglobal(state, "OnAllTrade") и, если успешно, далее заполняет табличку all_trade и вызывает полученную луа-функцию. То есть это как раз место, где вызывается OnAllTrade. В дампе крэш происходит вот где
а еще точнее вот где
с сообщениемТо есть lua_getglobal что-то (функцию OnAllTrade или nil) извлекает из реестра, пытается засунуть на вершину текущего стека, а туда нельзя писать. Осталось догадаться, а почему собсна нельзя-то, то ли стек реаллоцирован (как? все же под локом), то ли весь стейт (опять - как? все же под локом), то ли страница памяти недоступна. Последнее звучит глупо, но там дальше вызов колбека идет с установкой se_translator, это наводит на мысль, что могла случиться рекурсия под транслятором и in-page-error была неожиданно слопана. Мож попробовать транслятор заменить на явный SEH-фрейм и ловить в нем только то, что стоит ловить?

Ложная тревога. Скрипт 4 написан некорректно, потому сделки теряются.

добавлю свои пять копеек.
Если это особенности VMLua то разработчики ничего исправлять не будут.
VMLua написана не ими. Они лишь встраивают ее в КВИК и сделали dll интерфейса на луа с хранилищем терминала и обменом с сервером КВИК.
---------------------
Проблема многопоточности в луа - это проблема луа.
Есть различные решения этой проблемы, но они никак не связаны с КВИК.

Ва заблуждаетесь,
если бы все было так просто, то проблему многопоточности в луа не поднимали бы на форумах  уже лет ..надцать.
Вот, например, результат попытки решения критическими секциями (look, unlook)
и таких воплей в инете много.
--------------------
Тоже решал эту проблему, но не уверен, что нашел окончательное решение .

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

Многие решали, в том числе и основоположники. К сожалению, конкретно в их решении очереди блокирующие, эдакий qnx получился.

Есть такое.

Да, так. Надо пойти дальше и спросить, а в чем проблема синхронизации потоков. Она в синхронизации доступа к данным и только. У каждого потока есть свой (нативный) стек, поток также может выделить tls из кучи, и если он никуда больше не ходит, ему никакая синхронизация не требуется. Как только появляется какое-то разделяемое между потоками состояние, возникает проблема синхронизации доступа к нему. Посмотрим на примере. Берем два потока, совместно использующих один int. Если потоки лезут в этот int без синхронизации, имеем проблемы (даже int с точки зрения процессора не атомарен, атомарно можно его прочитать, но модифицировать уже нет). Защищаем int критической секцией. Все, проблем нет. Но если у нас два разделяемых int'а, появляется выбор: одна общая критическая секция на все разделяемое состояние или у каждого поля своя. Второй вариант это отличный способ огрести проблем: во-первых, появляется возможность дедлока, во-вторых, появляется проблема атомарности изменения обоих полей сразу. То есть лучше выбрать вариант раз с одной критической секцией на все разделяемое состояние, ценой более длительных блокировок всех потоков. В луа самом по себе вариант раз и использован, но есть нюансы*. А в квике получился вариант два, результаты которого в основном и вылезают то тут то там. Внутри квика это еще можно разрулить, зная, что и в каком порядке лочить, но как только к этой запутанной системе дан доступ внешнему кодеру через луа, открыт ящик пандоры, кодер завсегда придумает, как упорядочить свои обращения к состоянию так, чтобы повесить весь квик или получить неконсистентные результаты. Автор топика не раз просил арку дать возможность синхронизации из луа, но это, увы, не решит проблему, в квике нет одного общего лока на все, а еще один лок сделает только хуже.

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

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


* Если посмотреть в сорцы луа, увидим прекрасную вещь: сам по себе интерпретатор всегда работает под локом (пруф: поищите lua_lock /lua_unlock в этой функции). То есть, если выполняется только луа-код без вызовов функций, он весь атомарен (и другие потоки ждут). Лок снимается только перед вызовом си-функции. При этом встроенные библиотеки луа тоже состоят из си-функций, поэтому лок может быть снят (и тут же захвачен снова библиотечной функцией) в непредсказуемых местах, что убивает-таки атомарность изменения состояния как целого даже в луа без квика, при этом средств синхронизации со стороны луа не предоставлено. То есть луа защищает консистентность своего состояния, но не консистентность состояния пользовательского кода, с точки зрения луа-кодера он в той же ситуации, в какой и без луа, вот тебе потоки и рули как хочешь. Поэтому и говорю, что проблема не луа-специфичная, проблема в ожиданиях от луа чего-то, чего он не дает, хоть в нем и есть lua_lock.

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

Да, открывает.

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

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