Оптимизация советника, имеющего интеграцию с DLL-библиотекой

 
Друзья, мне очень нужна ваша помощь!

Описываю свою ситуацию, все просто:
Есть торговый бот, и есть dll библиотека, написанная на C# и подключенная к боту. При прогоне бота на истории всё срабатывает штатно, как задумано, однако при попытке прогнать сразу еще раз торговый бот на том же агенте (считай ядре), то прогона не происходит, и в журнале пишется только "disconnected" фактически сразу, как запускаешь. Через минут 5-10 очередной прогон становится доступен. Та же самая ситуация и во время оптимизации: на каждом агенте по 1 разу прогоняется без проблем, а дальше невозможно прогнать ни один из последующих прогонов.

Конечно же первым делом я так и подумал, что запущенная раз библиотека остается где-то в памяти агента, но она становится недоступной для последующих вызовов, пока Windows не удалит её из памяти. Но как сделать так, чтобы её можно было бы использовать при каждом прогоне? Во время оптимизации? Либо грохать её из памяти и создавать новую, либо наоборот достучатся до уже созданной ранее библиотеки?

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

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

#import "Dlib for MQL5.dll"
   string fn_CheckInfo(int);
   void   fn_CloseDLib(int);

#import

Файлы:
 

Поскольку с ex5-библиотеками, вроде, нет такой проблемы, то предполагаю рабочим вариант, когда делаете прокладку в виде ex5-библиотеки, в которой вызываете dll.

 
Vadim Lin:
Друзья, мне очень нужна ваша помощь!

Описываю свою ситуацию, все просто:
Есть торговый бот, и есть dll библиотека, написанная на C# и подключенная к боту. При прогоне бота на истории всё срабатывает штатно, как задумано, однако при попытке прогнать сразу еще раз торговый бот на том же агенте (считай ядре), то прогона не происходит, и в журнале пишется только "disconnected" фактически сразу, как запускаешь. Через минут 5-10 очередной прогон становится доступен. Та же самая ситуация и во время оптимизации: на каждом агенте по 1 разу прогоняется без проблем, а дальше невозможно прогнать ни один из последующих прогонов.


библиотека написана криво и не допускает повторное использование в том-же процессе (новую загрузку после выгрузки). 

 

Посмотрите вот это решение - https://www.mql5.com/en/forum/328579

В принципе, исходник и опции сборки библиотеки важны для решения проблемы.

Problems running EA with custom DLL in Strategy Tester. Am I doing something wrong, or is it a MT5 bug?
Problems running EA with custom DLL in Strategy Tester. Am I doing something wrong, or is it a MT5 bug?
  • 2019.12.16
  • [Deleted]
  • www.mql5.com
Hi, Summary: I'm testing an EA in Strategy Tester (ST) that uses a custom DLL...
 
Maxim Kuznetsov #:

библиотека написана криво и не допускает повторное использование в том-же процессе (новую загрузку после выгрузки). 

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


Ни переменных, ни вычислений, вроде этого:

static public void fn_CloseDLib(int _index)

{

}

 
fxsaber #:

Поскольку с ex5-библиотеками, вроде, нет такой проблемы, то предполагаю рабочим вариант, когда делаете прокладку в виде ex5-библиотеки, в которой вызываете dll.

Спасибо, попробую

 
Vadim Lin #:

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


Ни переменных, ни вычислений, вроде этого:

static public void fn_CloseDLib(int _index)

{

}

пустышка не проверит..

1) пустышка не имеет дальнейших зависимостей от других библиотек (а реальная библиотека как правило - имеет)

2) пустышка не имеет статических данных и соотв. их инициализации

3) компилятор на пустышку может не вставить (скорее всего так и есть, но не проверял) инициализацию ThreadLocalStorage, многие свистопляски и проблемы с выгрузкой/загрузкой, именно из-за неё

 
Maxim Kuznetsov #:

пустышка не проверит..

1) пустышка не имеет дальнейших зависимостей от других библиотек (а реальная библиотека как правило - имеет)

2) пустышка не имеет статических данных и соотв. их инициализации

3) компилятор на пустышку может не вставить (скорее всего так и есть, но не проверял) инициализацию ThreadLocalStorage, многие свистопляски и проблемы с выгрузкой/загрузкой, именно из-за неё

Он же в самом начале приложил эту пустышку и на ней яко-бы проблема воспроизводится. Нужно смотреть опции сборки.

 
Stanislav Korotky #:

Посмотрите вот это решение - https://www.mql5.com/en/forum/328579

В принципе, исходник и опции сборки библиотеки важны для решения проблемы.

Подготовил наглядный пример с исходниками проекта библиотеки на C# и на MQL.

Первый раз запускаешь - работает как надо, второй раз запускаешь - уже всё, не хочет.

Через небольшое количество времени (скажем через 3-5 минут) агент снова становится свободным, и готовым к повторному прогону, но тоже один раз.


Что касается оптимизации, то на сколько я понял - оптимизация легкой логики происходит без проблем на одном ядре (все прогоны работают без проблем), а вот с логикой потяжелее - не всегда.

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

Буду очень благодарен, если кто-то сможет помочь! 

Файлы:
 
Stanislav Korotky #:

Он же в самом начале приложил эту пустышку и на ней яко-бы проблема воспроизводится. Нужно смотреть опции сборки.

Вот я кстати тоже думаю, что возможно опции сборки могли каким-то боком повлиять, например версия фреймворка. Но не проверял пока что данную версию. Но на сколько я понимаю, библиотека должна быть именно x64, верно?

 
Maxim Kuznetsov #:

пустышка не проверит..

1) пустышка не имеет дальнейших зависимостей от других библиотек (а реальная библиотека как правило - имеет)

2) пустышка не имеет статических данных и соотв. их инициализации

3) компилятор на пустышку может не вставить (скорее всего так и есть, но не проверял) инициализацию ThreadLocalStorage, многие свистопляски и проблемы с выгрузкой/загрузкой, именно из-за неё

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