Ошибки, баги, вопросы - страница 2779
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я правильно понимаю, что асинхронными являются не только Set методы, но и Get?
Т.е. Ильяс тут был не прав?
При этом Слава здесь был прав, когда говорил о асинхронности метода ChartXYToTimePrice? Ведь метод ChartXYToTimePrice относится скорей всего к Get методам.
В документации про асинхронность говорится только про Set методы.
Нет. Методы Get являются синхронными, но их можно сгруппировать и выполнить одновременно, поэтому вызов метода 1 Get или 100 почти одинаков.
Методы set являются асинхронными, но они также могут быть сгруппированы для большей эффективности.
Таким образом, всегда лучше группировать «Задать вызовы вместе» и «Получать вызовы вместе», а не «Получить / установить / получить / установить / получить / установить».
Асинхронные вызовы более эффективны, если вызывающий поток не заблокирован во время выполнения функции, но вы потеряете эти преимущества, если смешаете Get и Set.
Надеюсь, это поможет, несмотря на перевод.
Если вы не понимаете сути того, о чем повествуете, то не нужно додумывать то, о чем вам не говорили.
Вы очень компетентны, без сомнения, но почему вы так высокомерны и неприятны? Если вы настолько умны, как думаете, вы наверняка поймете, что в ваших интересах улучшить свое поведение.
Это очень конструктивный пост, который я делаю, надеюсь, вы его услышите.
Ваш вопрос некорректный, так как в нем содержится утверждение того, о чем не повествовалось:
Напомнило из "Карлсона":
Сергей, не флудите пожалуйста. Можете ответить - ответьте, не хотите - не нужно самоутверждаться.
Не поревете, давно-давно уже ответил:
Вызов асинхронной как ChartSetInteger функции из основного потока быстрый, так как фактическое выполнение происходит в другом потоке.
С другой стороны вызов синхронной функции ChartGetInteger будет требовать синхронизации потоков, а на это может потребоваться дополнительно время.
Особенно заметны задержки, когда параллельный поток производит постоянное обновление данных структуры чарта (например, когда пользователь перемещает окно чарта или прокручивает историю).
К сожалению, выхлоп оказался не то что нулевым, а отрицательным...
Шаги для воспроизведения:
Невозможно не сказать Спасибо за такую работу! Надеюсь, по другим багам когда-нибудь получится что-то подобное.
Не поревете, давно-давно уже ответил:
К сожалению, выхлоп оказался не то что нулевым, а отрицательным...
Ну почему же отрицательным…
Ну не догнал с первого раза, ну не догнал со второго, но с третьего-то догнал.
Ну что поделать, если я такой тугой. В этом же нет Вашей вины.
Поэтому, не обижайтесь, Сергей.
У вас какое-то некорректное понимание терминов асинхронность и синхронность.
Когда говорят что функция асинхронная, то это значит, что она будет выполнена не в текущем потоке выполнения, а в каком-либо другом - параллельном.
Вызов асинхронной как ChartSetInteger функции из основного потока быстрый, так как фактическое выполнение происходит в другом потоке.
С другой стороны вызов синхронной функции ChartGetInteger будет требовать синхронизации потоков, а на это может потребоваться дополнительно время.
Особенно заметны задержки, когда параллельный поток производит постоянное обновление данных структуры чарта (например, когда пользователь перемещает окно чарта или прокручивает историю).
Скорее всего, для простоты и надежности используется один объект синхронизации для свей структуры данных чартов.
Можно попробовать улучшить скорость выполнения используя "сегментацию данных", однако с другой стороны теперь появляется возможность нарваться на дедлок, или недообновленные данные, или на замедление работы в других более критических местах.
В общем - лучше не трогать то, что и так стабильно работает.
Нет. Методы Get являются синхронными, но их можно сгруппировать и выполнить одновременно, поэтому вызов метода 1 Get или 100 почти одинаков.
Методы set являются асинхронными, но они также могут быть сгруппированы для большей эффективности.
Таким образом, всегда лучше группировать «Задать вызовы вместе» и «Получать вызовы вместе», а не «Получить / установить / получить / установить / получить / установить».
Асинхронные вызовы более эффективны, если вызывающий поток не заблокирован во время выполнения функции, но вы потеряете эти преимущества, если смешаете Get и Set.
Надеюсь, это поможет, несмотря на перевод.
Как я понял - Get синхронные, т.к. возвращают запрошенный результат. Но если в очереди есть асинхронные Set, то с ними приходится синхронизироваться.
Если в очереди только Get-ы, то задержек нет.
Спасибо всем. Потихоньку начинаю въезжать.
Теперь вырисовывается истинная картина таких задержек.
Как я понимаю (поправьте, пожалуйста, если не так):
При вызове метода Get из основного потока происходят запрос потоку самого чарта, который выполняется параллельно основному. Но поток чарта управляется непосредственно с основного потока методами Set и основной поток должен и так знать текущую характеристику чарта, но он только не знает текущее состояние потока чарта и не уверен, выполнены ли последние команды. Именно поэтому и происходит этот запрос, чтобы убедиться, что все предыдущие команды отработаны. А так-как метод Get синхронный, то он ожидает пока не придет ответ с параллельного потока чарта. Именно это является причиной задержек.
Если я ничего не напутал, то возникает вопрос:
Почему нельзя сделать так, чтобы параллельный поток докладывал основному потоку о том, что его команда выполнена и тогда основной поток отмечал бы команду выполненной и обновлял бы свою внутреннюю таблицу характеристик чарта? А на запрос Get бы выдавал данные из этой таблицы без запросов а параллельный поток. А в дополнение можно было бы еще передавать флаг о том, что ещё имеются невыполненные команды параллельному потоку чарта или все команды выполнены, чтобы понимать текущее состояние чарта. При такой схеме задержек не будет.
Примерно подобный механизм у меня реализован в классе iCanvas.
Вот демонстрирующий этот механизм индикатор, когда для связывания пиксельных координат канваса со временем и ценой чарта существует невероятно медленная функция ChartXYToTimePrice и создается ее аналог функция XYToTimePrice, которая обновляет свои внутренние статические переменные при наступлении события CHARTEVENT_CHART_CHANGE, и вычислет запрашиваемые параменты исходя из данных этой статической таблицы параметров чарта.
Спасибо всем. Потихоньку начинаю въезжать.
...Это верно. И, как сказал Ренат, кеш-систему необходимо реализовать на стороне mql. Возможно, это могло бы быть реализовано на стороне платформы, но это поставило бы под угрозу достижение наиболее производительной из возможных многопоточных архитектур.
Понятно.
Тем лучше для тех, кто понимает как реализовать эту кэш-систему, и хуже для тех, кто не понимает этого.