MQL4 потоки (thread/fork), это возможно? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вопрос тем, кто программирует на MQL, возможно ли в MQL создавать поток(и) или запускать процесс(скрипт) из эксперта, кто в теме дайте ссылку на материал?!?!??!.
https://www.mql5.com/ru/code/19003
Юрий, в индикатор вынес математику цикл в цикле, в результате работы функции бот молчит до 1 минуты, на форуме нашел тему, где ввиду отсутствия возможности создавать потоки одним из решений предлагалось использовать индикатор. Так вот обращение к индикатору в тот момент когда запускает функция анализа, через iCustom эксперт так же подвисает как и до того момента пока эта функция была в теле эксперта. Я предполагал, что в момент когда индикатор находиться в ступоре iCustom будет просто возвращает данные из предыдущего расчета, либо пустые данные, но к сожалению он просто подвисает пока функция не закончит свои вычисления.
Эксперт и индикатор написаны на MQL4.
Не путайте многопоточность с асинхронностью. Индикаторы в MQL действительно работают в отдельных потоках, но вызывая такой индикатор, Вам приходится дожидатся, когда он завершит свою работу и возратит нужный результат. Т.е. преимуществ при отправке синхронного запроса через iCustom (а iCustom всегда синхронный) нет.
Однако асинхронность как таковая не требует некой магии со стороны компилятора. Например можно реализовать алгоритм конечного автомата средствами MQL, который и будет имитировать эту самую асинхронность. Т.е. Вам необходимо в самом индикаторе разработать алгоритм, выдающий данные малыми "порциями". В этом случае зависания исчезнут. Но конечно это серьезное усложнение алгоритма, которое приходится делать из-за отсутствия асинхронного iCustom.
Не путайте многопоточность с асинхронностью. Индикаторы в MQL действительно работают в отдельных потоках, но вызывая такой индикатор, Вам приходится дожидатся, когда он завершит свою работу и возратит нужный результат. Т.е. преимуществ при отправке синхронного запроса через iCustom (а iCustom всегда синхронный) нет.
Однако асинхронность как таковая не требует некой магии со стороны компилятора. Например можно реализовать алгоритм конечного автомата средствами MQL, который и будет имитировать эту самую асинхронность. Т.е. Вам необходимо в самом индикаторе разработать алгоритм, выдающий данные малыми "порциями". В этом случае зависания исчезнут. Но конечно это серьезное усложнение алгоритма, которое приходится делать из-за отсутствия асинхронного iCustom.
Ммм..... да же не знаю....
Общего стажа как программиста у меня около 22 лет, в MQL c 2009 года, да есть наверное моменты о которых мне ничего не известно, так как в практической плоскости ранее ими не пользовался в MQL, но Ваше "Т.е. Вам необходимо в самом индикаторе разработать алгоритм выдающий данные малыми "порциями"", это.... К сожалению, если бы это было возможно, я бы так сделал, так как оптимизация это мой бич.
"iCustom (а iCustom всегда синхронный) нет" вы правы на 100%, но в постах форума по схожим темам, были рекомендации как обойти отсутствие в MQL создания потоков (асинхронных, вообще никогда не задумывался о том, что говорят о thread надо подчеркивать особенность асинхронности), уверенно утверждалось, что индикатор простейший способ этой проблемы (я поверил).
если речь идет исключительно об MT4, то индикатор вызванный через iCustom() никак не может решить проблему многопоточности вычислений
Справочник MQL4 / Программы MQL4 / Выполнение программ
Каждый скрипт и каждый эксперт работает в собственном отдельном потоке. Все индикаторы работают в одном интерфейсном потоке терминала. Обработка тиков и синхронизация истории также производится в интерфейсном потоке. Если пользовательский индикатор вызван при помощи функции iCustom(), то этот индикатор работает в потоке вызвавшей его программы. Библиотечные (импортируемые) функции также работают в потоке вызывающей программы.
При запуске эксперта ему необходимо обеспечить актуальное торговое окружение, доступность истории по данному символу и периоду, а также произвести синхронизацию между терминалом и сервером. На эти процедуры терминал предоставляет эксперту отсрочку запуска не более чем в 5 секунд, по истечении которых эксперт будет запущен с теми данными, что удалось подготовить. Поэтому при отсутствии связи с сервером это может привести к задержке запуска эксперта.ы MQL4 / Выполнение программ
все что можно "выжать" из этой справки, это имеем:
- по одному потоку на каждого запущенного эксперта или скрипта, причем использование iCustom() не добавляет поток
- один поток на все индикаторы которые были запущены "руками" в терминале
Ну и итого, или много экспертов вызывающих iCustom() - будет несколько потоков или 2 потока: эксперт + индикатор запущенный руками. Но в обоих случаях придется решать проблему с обменом данных.
Ммм..... да же не знаю....
Общего стажа как программиста у меня около 22 лет, в MQL c 2009 года, да есть наверное моменты о которых мне ничего не известно, так как в практической плоскости ранее ими не пользовался в MQL, но Ваше "Т.е. Вам необходимо в самом индикаторе разработать алгоритм выдающий данные малыми "порциями"", это.... К сожалению, если бы это было возможно, я бы так сделал, так как оптимизация это мой бич.
"iCustom (а iCustom всегда синхронный) нет" вы правы на 100%, но в постах форума по схожим темам, были рекомендации как обойти отсутствие в MQL создания потоков (асинхронных, вообще никогда не задумывался о том, что говорят о thread надо подчеркивать особенность асинхронности), уверенно утверждалось, что индикатор простейший способ этой проблемы (я поверил).
Если проблемы именно на этапе оптимизации, то мой Вам совет не подойдет. Ускорить вычисления используя дополнительные потоки Вы не сможете. Нужные иные способы.
Если проблемы именно на этапе оптимизации, то мой Вам совет не подойдет. Ускорить вычисления используя дополнительные потоки Вы не сможете. Нужные иные способы.
Иной способ это писать отдельную прогу для предобработки, но хотелось этого избежать ((((.
На самом деле надеялся, что к индикатору можно будет обращаться в асинхронном режиме или он хотя бы будет давать ошибки, а не зависать.
Если проблемы именно на этапе оптимизации, то мой Вам совет не подойдет. Ускорить вычисления используя дополнительные потоки Вы не сможете. Нужные иные способы.
В моем случае не было попытки "ускорить", все достаточно тривиально, просто хотел избавить эксперт от вычислений которые мешают ему, в реальном режиме времени принимать решения (открытие/закрытие/модификация) по позициям, пока он находится в состоянии перерасчет.
Для этого мне нужен асинхронный поток.
В моем случае не было попытки "ускорить", все достаточно тривиально, просто хотел избавить эксперт от вычислений которые мешают ему, в реальном режиме времени принимать решения (открытие/закрытие/модификация) по позициям, пока он находится в состоянии перерасчет.
Для этого мне нужен асинхронный поток.
ну у Вас вариантов не много - или изучить эту возможность на MQl5 - не читал подробно, может быть там существует многопоточность в iCustom()
или придется в .dll выносить расчеты и мьютексами и семафорами согласовывать ввод/вывод/расчет
В моем случае не было попытки "ускорить", все достаточно тривиально, просто хотел избавить эксперт от вычислений которые мешают ему, в реальном режиме времени принимать решения (открытие/закрытие/модификация) по позициям, пока он находится в состоянии перерасчет.
Для этого мне нужен асинхронный поток.
Ну так в чем же проблема? Сделайте индикатор асинхронным. Что такое асинхронность? - это просто способ разрыва связки запрос-ответ. Т.е. Вы делаете запрос, а ответ получаете когда-нибудь потом. При этом ответ тоже рассчитывается когда-то потом, а не в момент первого обращения. Вместо ответа Вам вовращается некий контракт, который говорит, что запрос получен и над его результатами началась работа. Применительно к ICustom и индикатору асинхронность можно попробовать сделать через систему умных вычислений, когда индикатор лопатит не все бары от prev_calculated до текущего бара, а делает это по-умному, малыми порциями. Получив значение по последнему бару EMPTY_VALUE можно понять что индикатор еще не обсчитал все значения и продолжить вызывать iCustom в неблокирующей манере. Все тормоза при этом исчезнут, а эксперт будет понимать, что нужно подождать.
ну у Вас вариантов не много - или изучить эту возможность на MQl5 - не читал подробно, может быть там существует многопоточность в iCustom()
или придется в .dll выносить расчеты и мьютексами и семафорами согласовывать ввод/вывод/расчет