Есть ли система прерываний при обработки событий MT4. Если при обработке события NewTick обработчиком OnTick, происходит событие Timer, то какой сценарий выполняется: - страница 5

Новый комментарий
 
Yury Kirillov:
В моём советнике критичные к скорости выполнения расчеты должны выполняться по приходу нового тика. Прочие расчеты и различного рода отображения информации должны выполняться во время простоя советника между завершением обработки прошлого тика и приходом будущего. Я использую миллисекундный таймер для инициирования попыток обработки некритичных расчетов. Поэтому мне важно, чтобы расчеты по таймеру не мешали расчетам по приходу тиков. Отсюда и интерес к системе обработчиков и порядку их взаимодействия.

Ну никто же не заставляет все, что происходит в терминале, реализоваться в виде одной MQL-программы.

 

В советнике должны быть ТОЛЬКО торговые критически-важные дела - потому что это логично. Все остальное - в другой MQL-программме: еще один советник или индикатор. 

 
fxsaber:

Ну никто же не заставляет все, что происходит в терминале, реализоваться в виде одной MQL-программы.

 

В советнике должны быть ТОЛЬКО торговые критически-важные дела - потому что это логично. Все остальное - в другой MQL-программме: еще один советник или индикатор. 

Да хоть сколько можно программ сделать, но терминал может одновременно обрабатывать только одну команду. Поэтому когда несколько советников висят на одном терминале я всегда проверяю занятость канала. Как не разбивай, а все равно очередь ( Единственный, видимый для меня, вариант - это иметь возможность ручного прерывания или ручного запуска проверки события. Если приказ уде висит на терминале, то остается только ждать (например открытие или закрытие ордеров)
 
Сергей:
Да хоть сколько можно программ сделать, но терминал может одновременно обрабатывать только одну команду. Поэтому когда несколько советников висят на одном терминале я всегда проверяю занятость канала. Как не разбивай, а все равно очередь ( Единственный, видимый для меня, вариант - это иметь возможность ручного прерывания или ручного запуска проверки события. Если приказ уде висит на терминале, то остается только ждать (например открытие или закрытие ордеров)
Мне кажется, я свое мнение развил. К сожалению не могу постоянно быть на форуме.

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

Ошибаетесь. Здесь будет 2 потока. Рабочий поток тиков никогда ничего не ждет кроме новых тиков и обрабатывает их сразу по приходу, отправляя нотификацию медленному потоку.

Медленный поток обновляет свое состояние когда успевает. На быстром потоке тиков это никак не сказывается.

 
Stanislav Korotky:

Ошибаетесь. Здесь будет 2 потока. Рабочий поток тиков никогда ничего не ждет кроме новых тиков и обрабатывает их сразу по приходу, отправляя нотификацию медленному потоку.

Медленный поток обновляет свое состояние когда успевает. На быстром потоке тиков это никак не сказывается.

Не буду спорить, Вы писали про связной протокол. Протокол запуститься только согласно очереди. Именно это я и писал. Потеряете время на переменных и их сохранении, но протокол запуститься все равно по очереди, ведь советник связан им с индикатором. А вот управлять событиями не факт, что получится при таком подходе, нет способа приостановки на время выполнения. Можно клина поймать.

Еще раз извиняюсь, все, что написал исключительно мое видение. Упехов


 
Сергей:
Не буду спорить, Вы писали про связной протокол. Протокол запуститься только согласно очереди. Именно это я и писал. Потеряете время на переменных и их сохранении, но протокол запуститься все равно по очереди, ведь советник связан им с индикатором. А вот управлять событиями не факт, что получится при таком подходе, нет способа приостановки на время выполнения. Можно клина поймать.

Протокол проектирует разработчик. Если разработчик в курсе только синхронных протоколов, то действительно у него будут блокировки. Если он знает принципы асинхронной и односторонней передачи данных, то может сделать протокол, отвечающей поставленной задаче - без потерь времени в высокоприоритетном потоке. В частности, постановка в очередь может быть неблокирующей.
 
Stanislav Korotky:
Протокол проектирует разработчик. Если разработчик в курсе только синхронных протоколов, то действительно у него будут блокировки. Если он знает принципы асинхронной и односторонней передачи данных, то может сделать протокол, отвечающей поставленной задаче - без потерь времени в высокоприоритетном потоке.
т.е. Вы можете предложить вариант протокола, прерывающего или управляемо игнорирующего событие онтик в советнике без использования цикла? Вопрос автора был в этом
 
Сергей:
Да хоть сколько можно программ сделать, но терминал может одновременно обрабатывать только одну команду.
Давно не так.
 
fxsaber:
Давно не так.
выписка из последней документации:

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

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

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

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

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

Поэтому я всегда проверяю очередность. Сам разработчик гарантии не дает. Лучше руками разрулить. Но я пишу только для себя и пользуюсь только своими советниками, поэтому мне проще. Если имеется набор чужих, то я бы их разносил по разным терминалам. А то в самый неподходящий момент стрельнет ...
  1. Тема про MT4.
  2. Очередь OnTradeTransaction никак не влияет на скорость и успешность исполнения.
123456
Новый комментарий