Асинхронное и многопоточное программирование в MQL - страница 19
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
...
еще раз, повторю: ответьте на вопрос зачем это нужно торговому терминалу?
...А терминал работает в одном потоке? Если во множестве, значит все таки зачем то нужно?)))
Можно много рассуждать.
хм, и Вы туда же куда и топикстартер? - много пишете, но не читаете и не хотите развиваться? - Вы не успели бы по моей ссылке не то, что осмыслить статью, но даже прочитать, вот из последнего, что у себя нашел, вот мой код по "3-м экранам Элдера", писал кому то, у меня структура кода всегда примерно такая (при условии , что не будут еще доработки изменяющие основную логику, там код ... лучше не вспоминать, во что можно превратить изначально линейный структурированный код ((( )
ниже будут все служебные функции, но сам основной код - сама ТС максимально читаемая и максимально линейная логика, я всегда так писал, в Универе преподаватели только такие исходники принимали в качестве сданной работы, иначе не сдашь )))
к чему это? - да к тому, что еще раз: многопоточность нужно применять лишь в случае если нет другого решения, вот просто так никто из адекватных программистов не уйдет в работу с асинхронными операциями! - это больно! ))))
пример будет от Вас: ответьте на вопрос зачем это нужно торговому терминалу?
Да, в доках есть, а реально нет. Насколько я понял.
Сейчас попробовал. Всё работает.
Хотя практической пользы в MQL от них действительно нет.
Ответьте на вопрос зачем это нужно торговому терминалу?
...
пример будет от Вас: ответьте на вопрос зачем это нужно торговому терминалу?
Я Вам уже отвечал. Вы игнорируете.
1. Мне нужна многопоточность, потому что мои программы на порядок сложнее. Я хочу объединить в одной программе очень много тяжелых функций. Трехмерная визуализация, общение с сервером, GUI, и различные вычисления. Одного потока недостаточно. Значит, нужно либо разбивать программу на части, либо использовать штатную многопоточность. Если ее не будет, значит разобью программу на части.
2. Терминал многопоточен сам по себе. Зачем ему многопоточность - спросите у его разработчиков. Зачем многопоточность мне,- см. пункт 1.
Igor Makanu
пример будет от Вас: ответьте на вопрос зачем это нужно торговому терминалу?
Ну самый очевидный - отдельный интерфейсный поток, особенно критично для гуйни, хотя сам без неё обхожусь.
ЗЫ: я за многопоточность не агитирую, если что.
Я Вам уже отвечал. Вы игнорируете.
1. Мне нужна многопоточность, потому что мои программы на порядок сложнее. Я хочу объединить в одной программе очень много тяжелых функций. Трехмерная визуализация, общение с сервером, GUI, и различные вычисления. Одного потока недостаточно. Значит, нужно либо разбивать программу на части, либо использовать штатную многопоточность. Если ее не будет, значит разобью программу на части.
2. Терминал многопоточен сам по себе. Зачем ему многопоточность - спросите у его разработчиков. Зачем многопоточность мне,- см. пункт 1.
Вы тоже игнорируете, что Вам пишут, я уже писал: мухи отдельно - котлеты отдельно! графический интерфейс и торговая стратегия не должны выполняться в одном коде!
В Вашем топике про Ваш подход к графическим интерфейсам, Вам сказали, что Ваш код не эффективный, и Вы думаете, что выбросив часть функций в отдельный поток у Вас возрастет производительность? - производительность не возрастет, но появится дополнительный геморой, как теперь все синхронизировать ))))
ЗЫ: Вспомнил общение юзверей на 4пда в топиках про Андроид - девайсы, юзвери убеждены в эффективности версии прошивки лишь по количеству свободной памяти, причем с точностью до наоборот - чем больше свободной памяти, тем круче прошивка, но к сожалению, нет понимания, что ОС должна эффективно использовать все ресурсы - включая память, если много свободной памяти, не факт, что ОС эффективно использует ресурсы. Так и у Вас, Вы не можете в одном потоке добиться производительности, значит нужно больше потоков! - может дело все таки не в возможностях языка (платформы, ОС..), а в разработчике? - может он не эффективен? ;) - я в прошлом году проверял графические интерфейсы из цикла статей и в КБ, не увидел явных притормаживаний, все работает на хорошем уровне. Я смотрел исходники этих кодов, схемы обхода элементов интерфейсов, сами подходы ООП - все очень похоже на принципы работы графики в Виндовс - почему у них все работает, а у Вас нет? )))))) - возможно все таки изначальный подход был не правильным? или теоретическая подготовка хромает на обе лапы?
Вы тоже игнорируете, что Вам пишут, я уже писал: мухи отдельно - котлеты отдельно! графический интерфейс и торговая стратегия не должны выполняться в одном коде!
В Вашем топике про Ваш подход к графическим интерфейсам, Вам сказали, что Ваш код не эффективный, и Вы думаете, что выбросив часть функций в отдельный поток у Вас возрастет производительность? - производительность не возрастет, но появится дополнительный геморой, как теперь все синхронизировать ))))
ЗЫ: Вспомнил общение юзверей на 4пда в топиках про Андроид - девайсы, юзвери убеждены в эффективности версии прошивки лишь по количеству свободной памяти, причем с точностью до наоборот - чем больше свободной памяти, тем круче прошивка, но к сожалению, нет понимания, что ОС должна эффективно использовать все ресурсы - включая память, если много свободной памяти, не факт, что ОС эффективно использует ресурсы. Так и у Вас, Вы не можете в одном потоке добиться производительности, значит нужно больше потоков! - может дело все таки не в возможностях языка (платформы, ОС..), а в разработчике? - может он не эффективен? ;) - я в прошлом году проверял графические интерфейсы из цикла статей и в КБ, не увидел явных притормаживаний, все работает на хорошем уровне. Я смотрел исходники этих кодов, схемы обхода элементов интерфейсов, сами подходы ООП - все очень похоже на принципы работы графики в Виндовс - почему у них все работает, а у Вас нет? )))))) - возможно все таки изначальный подход был не правильным? или теоретическая подготовка хромает на обе лапы?
Почему Вы решили, что у меня что то неэффективно или не работает? Зайдите ко мне в профиль и посмотрите, как все работает. Именно потому что все работает и развивается, я предполагаю скорую необходимость в многопоточности.
Ну самый очевидный - отдельный интерфейсный поток, особенно критично для гуйни, хотя сам без неё обхожусь.
ЗЫ: я за многопоточность не агитирую, если что.
Ну, у вас нет продуктов в Маркете. Зачем тогда делать ГУИ на МКЛ, если он легко делается на C#, который теперь легко подключается к МКЛ. И этот ГУИ уже изначально работает в своем потоке.
Вот для наглядного примера, примерное написание линейного асинхронного кода в одном потоке.
При условии, что в mql штатно реализован функционал EventLoop и реализован разработчиками ThreadPool.
Юзеру в потоки лезть не нужно! Разработчики должны об этом позаботится написав соответствующие классы.
Программа работает в одном потоке, а штатные неблокирующие колбэки исполняются в пуле потоков!
Теперь замените ваши простые функции в колбэках, на функции с тяжёлыми расчетами или требующие параллельности.
Мега удобно и всё параллельно ))