Есть ли система прерываний при обработки событий MT4. Если при обработке события NewTick обработчиком OnTick, происходит событие Timer, то какой сценарий выполняется: - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В настоящий момент у меня используется следующий алгоритм обработки тиков и таймера:
void OnTick(){
...
On_Tick(TICK_MODE_HIGH);
...
}//OnTick()
//
//----- Обработчик таймера
void OnTimer(){
...
On_Tick(TICK_MODE_LOW);
...
}//OnTimer()
//
//----- Основной алгоритм обработки
void On_Tick(TickModes iTickMode){
...
<расчеты высокого приоритета>
...
{if(iTickMode==TICK_MODE_LOW)
{
<расчеты низкого приоритета>
}}
...
}//On_Tick()
Есть ли какие-то недостатки такого метода против метода зацикливания? Или наоборот - чем метод зацикливания может быть выгоднее?
В настоящий момент у меня используется следующий алгоритм обработки тиков и таймера:
void OnTick(){
...
On_Tick(TICK_MODE_HIGH);
...
}//OnTick()
//
//----- Обработчик таймера
void OnTimer(){
...
On_Tick(TICK_MODE_LOW);
...
}//OnTimer()
//
//----- Основной алгоритм обработки
void On_Tick(TickModes iTickMode){
...
<расчеты высокого приоритета>
...
{if(iTickMode==TICK_MODE_LOW)
{
<расчеты низкого приоритета>
}}
...
}//On_Tick()
Есть ли какие-то недостатки такого метода против метода зацикливания? Или наоборот - чем метод зацикливания может быть выгоднее?
Надо понять, что Вам важно. Как я понял из Вашего поста, Вам важнее событие по таймеру. В стандартном варианте с приходом тика событие онтик возьмет управление на себя и если в это время появится событие онтайм оно будет проигнорировано. Что и будет в Вашем варианте кода. Если важно четко ловить таймер, используйте цикл ...
Скорее как раз наоборот. Мне важно выполнять критичные расчеты связанные с торговлей как можно быстрее при приходе нового тика. Менее критичные расчеты, связанные с отображением статистики, с расчетом параметров по закрытым барам, обработку запросов к сайтам, файловые операции - хотелось бы выполнять в свободное от расчетов критичных параметров время. Меня бы очень устроило, если бы второстепенные расчеты вообще прерывались при поступлении нового тика и выполнении критичных расчетов. То есть мне важно не пропускать тиковые расчеты, но время от времени нужно выполнять и некоторые дополнительные. Поэтому и пытаюсь разобраться с возможностями OnTick() и OnTimer() применительно к моим запросам.
Задержка в несколько секунд :-) для тикового советника многовато!
Для проверки на новый тик можно использовать SymbolInfoTick() с анализом времени прихода последнего тика, если время изменилось - можно обсчитывать новый тик, если не изменилось - можно обсчитывать второстепенные операции. Но советник на зацикливании имеет существенный недостаток - он всегда потребляет ресурсы, всегда находится в работе. В противоположность этому советники с обработкой тиков (без зацикливания) и таймера вроде бы имеют временные отрезки без потребления ресурсов - когда новых тиков и событий таймера ещё нет, а старые уже отработаны.
Задержка в несколько секунд :-) для тикового советника многовато!
Для проверки на новый тик можно использовать SymbolInfoTick() с анализом времени прихода последнего тика, если время изменилось - можно обсчитывать новый тик, если не изменилось - можно обсчитывать второстепенные операции. Но советник на зацикливании имеет существенный недостаток - он всегда потребляет ресурсы, всегда находится в работе. В противоположность этому советники с обработкой тиков (без зацикливания) и таймера вроде бы имеют временные отрезки без потребления ресурсов - когда новых тиков и событий таймера ещё нет, а старые уже отработаны.
В моём советнике критичные к скорости выполнения расчеты должны выполняться по приходу нового тика. Прочие расчеты и различного рода отображения информации должны выполняться во время простоя советника между завершением обработки прошлого тика и приходом будущего. Я использую миллисекундный таймер для инициирования попыток обработки некритичных расчетов. Поэтому мне важно, чтобы расчеты по таймеру не мешали расчетам по приходу тиков. Отсюда и интерес к системе обработчиков и порядку их взаимодействия.
Чудес не бывает. Какой бы способ кодирования ни был выбран, если в отсутствии тиков запутится фрагмент кода низкоприоритетного кода (из "OnTimer"), то ничто не сможет гарантировать, что в этот момент не появится новый тик, и он не сможет быть обработан до тех пор, пока низкоприоритетный фрагмент не завершит работу.
Поток - один. Точка.
Чтобы решить проблему, следует использовать два независимых модуля:
- эксперт, обрабатывающий тики (у него свой поток);
- индикатор, предоставляющий медленное отображение (другой поток);
Для общения эксперта и индикатора следует разработать протокол (через глобальные переменные или что-то еще).
Чудес не бывает. Какой бы способ кодирования ни был выбран, если в отсутствии тиков запутится фрагмент кода низкоприоритетного кода (из "OnTimer"), то ничто не сможет гарантировать, что в этот момент не появится новый тик, и он не сможет быть обработан до тех пор, пока низкоприоритетный фрагмент не завершит работу.
Поток - один. Точка.
Чтобы решить проблему, следует использовать два независимых модуля:
- эксперт, обрабатывающий тики (у него свой поток);
- индикатор, предоставляющий медленное отображение (другой поток);
Для общения эксперта и индикатора следует разработать протокол (через глобальные переменные или что-то еще).
замкнутый круг ... Как только появится протокол общения этот протокол сразу встанет в очередь. В цикле Вы можете проверять приход тика когда хотите, даже внутри таймера. Т.е. Вы можете прервать обработку одного события в пользу другого. Больше вариантов прерывания события я не вижу ...