MT5 и скорость в боевом исполнении - страница 74
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Можете конкретизировать эти объективные причины?
Неоправданные тормоза
Если тут не понимают о чём тут пишут, извините, это не моя проблема, а тех кто не выкуривает тему разговора.
Нет. Это - твоя проблема. Именно ты поднял этот вопрос, не понимая сути и последствий.
Многократно обсуждалось здесь за более, чем 10 лет.
Неоправданные тормоза
То есть менеджер задач выполняющийся в цикле событий, раскидывая несколько задач (равные количеству обработчиков) будет вызывать тормоза?
Ведь обработчиков не так много, всего несколько штук. Их просто нужно раскидать по задачам и отпустить в свой цикл обработки событий.
При этом контролировать флаг выполнения обработчика. Отработал обработчик, сбросили флаг, и так по кругу.
Что то как то не верится в тормоза, это же не все события обрабатываем, а только равное количеству обработчиков.
А у самих обработчиков уже свои события.
То есть менеджер задач выполняющийся в цикле событий, раскидывая несколько задач (равные количеству обработчиков) будет вызывать тормоза?
Ведь обработчиков не так много, всего несколько штук. Их просто нужно раскидать по задачам и отпустить в свой цикл обработки событий.
При этом контролировать флаг выполнения обработчика. Отработал обработчик, сбросили флаг, и так по кругу.
Что то как то не вернется в тормоза, это же не все события обрабатываем, а только равное количеству обработчиков.
А у самих обработчиков уже свои события.
Там, где есть писатель, читатель должен ждать. Пока писатель не напишет.
Если читателя несколько, то он должен договориться сам с собой про свои переменные. Пока одна инкарнация меняет содержимое переменной, другие ждут. Даже если других инкарнаций в данный момент нету, блокировка ресурса всё равно идёт в ядро системы, дорогая операция. Веселуха начнётся, когда все инкарнации пойдут за торговым окружением. Не дай бог торговать одновременно начнут
В общем, молодёжь не слушает, что им рассказывают. Многократно. С примерами. С объяснениями. Больше 10 лет подряд
Нет. Это - твоя проблема. Именно ты поднял этот вопрос, не понимая сути и последствий.
Многократно обсуждалось здесь за более, чем 10 лет.
От оппонентов я только видел неадекватные нападки, а не конструктивное обсуждение.
Если бы своевременно вы бы вмешались в общение с пояснением, то и не было бы лишних вопросов.
А когда разработчик молчит, не знаешь что и думать. За 10 лет многое что изменилось в мире технологий.
Ладно, теперь я понимаю, что вы услышали меня, надеюсь подумаете ещё раз над этим вопросом. Может и получится решить, реально было бы круто.
От оппонентов я только видел неадекватные нападки, а не конструктивное обсуждение.
Если бы своевременно вы бы вмешались в общение с пояснением, то и не было бы лишних вопросов.
А когда разработчик молчит, не знаешь что и думать. За 10 лет многое что изменилось в мире технологий.
Ладно, теперь я понимаю, что вы услышали меня, надеюсь подумаете ещё раз над этим вопросом. Может и получится решить, реально было бы круто.
Неадекватные нападки - «шо, опять?»
Нормальные все ответы были. Нападки были только от меня. Прошу меня простить, если обидел.
А парни вполне адекватно отвечали.
Там, где есть писатель, читатель должен ждать. Пока писатель не напишет.
Если читателя несколько, то он должен договориться сам с собой про свои переменные.
Пока одна инкарнация меняет содержимое переменной, другие ждут.
Даже если других инкарнаций в данный момент нету, блокировка ресурса всё равно идёт в ядро системы, дорогая операция.
Веселуха начнётся, когда все инкарнации пойдут за торговым окружением. Не дай бог торговать одновременно начнут
В общем, молодёжь не слушает, что им рассказывают. Многократно. С примерами. С объяснениями. Больше 10 лет подряд
Как я понял из выше сказанного, проблема в самой синхронизации писателя/читателя, которая может быть дорогой.
Нет синхронизации, нет проблем. Хм, лаконично мудро, со стороны оптимизации. Спасибо за пояснение дядь Слав ))
Прошу тоже на меня не сердчать. Я не волшебник, я только учусь ))
Просто не пойму, в системах реального времени, там ведь всё работает в многозадачном режиме, и процедура синхронизации основной инструмент.
Получается и OSRT тормозная система? Как то не логично. Хотя есть и дедлайн, латентность, джиттер.
А что скажите по объектной модели, тут тогда гонка возникает? Или чем может быть чреват такой подход?
https://www.mql5.com/ru/code/31306
Или чем может быть чреват такой подход?
https://www.mql5.com/ru/code/31306
А чем он может быть чреват?
Привет Николай. Так то оно так.
Но не будет ли той же проблемы как с синхронизацией? о которой говорит Слава, то есть неоправданные тормоза.
А может и нет проблемы? )) Может просто проще не применять асинхронную модель, чем синхронизировать с приоритетами? ))
Привет Николай. Так то оно так.
Но не будет ли той же проблемы как с синхронизацией? о которой говорит Слава, то есть неоправданные тормоза.
А может и нет проблемы? )) Может просто проще не применять асинхронную модель, чем синхронизировать с приоритетами? ))
я не знаток. в графах. Важность определяется зависимостью начала исполнения других задач от окончания текущей. другие критерии вторичны. но есть так же время исполнения задачи. и оно тоже важнейшее среди одноранговых. В общем сложно и самая грусть, заложенный алгоритм приоритетов на ходу изменить не возможно. По хорошему, хотелось бы разьяснений от разрабов до возникновения вопросов. Сложно, но это правильная цель в развитии среды.