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