Асинхронное и многопоточное программирование в MQL - страница 13

 
Реter Konow:

Вот если добавят многопоточность, Вам разве хуже станет? И так добавили кучу всего в MQL, а это реально полезная вещь. Но пользу ее может понять только человек, который пишет на MQL очень сложные, громоздкие программы. Если Вы не понимаете зачем нужна многопоточность, то значит таких программ Вы не пишете. Когда будете писать, поймете. Все просто. ))

Многопоточность определенно нужна, особенно в тестере, особенно в мультиинструментальном режиме. Мне часто нехватает производительности. Но я не специалист в области программирования и тонкости не очень понимаю, знаю только, что мне нужно считать много всего и параллельно). И распараллелить тестер было бы крайне полезно. 
 
Реter Konow:

Вот если добавят многопоточность, Вам разве хуже станет? 

однозначно нет - это будет лучше, ! - НО тут ключевой вопрос в поддержке - кто будет это объяснять как использовать? - кто будет устранять баги? - кто обеспечит гарантированно понятный функционал?

По основной идее разработчиков как и кому использовать МТ, они предоставляют функционал соответствующий С++, тем самым снимая с себя "головную боль" по обучению и объяснению как это работает - литературы в сети по С++ и примеры написания программ начального уровня в сети за 20 лет собралось очень много

Вы видели готовый пакет (по задаче ТС) который был бы применен к С++ ?

 
Igor Makanu:

"специалистами"? - с Вами не о чем разговаривать,  засуньте свое имхо... на этом ресурсе большое MQL  сообщество, с Профессионалами в разных областях, к сожалению, Вы не показали ни одного своего знания полезного сообществу, можете опять обвинить меня во всем что вздумается-  "Вы же специалист ! "


разработчики сделают? - что и зачем? не известный юзер, не может объяснить ДАЖЕ СЕБЕ ЗАЧЕМ ЭТО НУЖНО? )))

какая цель MetaQoutes? - цель, как любой ИТ-компании получение прибыли! , но не знаю почему, компания MetaQoutes очень серьезно занимается  продвижением своих услуг, очень много сделано работы, чтобы популяризовать алготрейдинг, чтобы дать аналитический материал, чтобы создать интернет - сообщество... такой благотворительностью  занимаются единицы ИТ-компаний, обычно это ИТ-гиганты

так вот, компания тратит свои ресурсы на то, что в дальнейшем (не факт), что принесет прибыль.... а тут вот раз... появился юзер, которому нужно адаптировать концепцию тормознутого Python или Java в MQl.... Вам не смешно? - годов то сколько Вам?  ))))


однозначно - уважаю, зачастую только упорство помогает найти свою нишу в этой жизни!  Удачи в этом нелегком труде!

Это с вами не о чем разговаривать по данной теме!
У вас даже логики не хватает чтобы понять, какую эффективную пользу для MetaQuotes, принесёт возможность писать асинхронные программы.
И привлечет действительно специалистов, кто пишет асинхронные программы.  
А в сообществе достаточно адекватных специалистов, с которыми можно обсуждать проблемы и идеи, а не выслушивать своё я, я же специалист.
Увы чтобы быть специалистом, нужно идти в ногу с технологиями, и не важно в каких языках они используются.
Вы даже не слышите что вам пишут, что на С++ так же пишут асинхронно, но вам видимо этого не понять, вы не ставили себе асинхронные задачи.
И давайте умерьте свой пыл, вы даже общаться нормально не можете.

 
Roman:

Это с вами не о чем разговаривать по данной теме!

не разговаривайте, но ответа до сих пор нет:


ответьте на вопрос зачем это нужно торговому терминалу?
 
Maxim Romanov:
Многопоточность определенно нужна, особенно в тестере, особенно в мультиинструментальном режиме. Мне часто нехватает производительности. Но я не специалист в области программирования и тонкости не очень понимаю, знаю только, что мне нужно считать много всего и параллельно). И распараллелить тестер было бы крайне полезно. 
А я собираюсь трехмерную визуализацию разрабатывать, и помещать ее в один поток с вычислениями, событиями интерфейса, внешними событиями (обращение к серверу) нецелесообразно. ДЛЛ не подходит всегда по одной причине - нельзя свободно распостронять программы.
 
Igor Makanu:

однозначно нет - это будет лучше, ! - НО тут ключевой вопрос в поддержке - кто будет это объяснять как использовать? - кто будет устранять баги? - кто обеспечит гарантированно понятный функционал?

...

С моей точки зрения, это наименьшая проблема. Главное другое - люди будут общаться на эту тему. Форуму необходимы новые темы. Разве нет? Получается, только лучше будет. Ну, что критичного случится, если будут проблемы и баги у пользователей? А когда их небыло? )

 
Andrey Pogoreltsev:

Вы требуете асинхронного выполнения запросов, но приводите в пример многопоточность... Я призывал вас разобраться в этом, но вы так и не разобрались.

Я расписал вам решение именно вашей задачи тут: https://www.mql5.com/ru/forum/318593/page4#comment_12568119

Но, уверен, вы даже не изучили данную тему.

По-моему, если вам дать ассинхронную очередь, вы будете по-прежнему вопрошать к многопоточности... Попробуйте хотя бы для начала разобраться с OVERLAPPED и эвентами, вы же просите WinAPI в код?)

Если в терминал внести многопоточность, он загнется от горе-программистов, быстрее скорости света.

Программисты ищут решения задач, а не просят фреймворк измениться под их невежество.

Не не, ошибаетесь, я все посмотрел буду разбираться однозначно.
Кстати вы единственный, кто дал хоть какое то верное направление благодарю, от остальных только флуд.
Тут просто многие не понимают сути темы, по этому пришлось отвечать на их вопросы. Вот и разрослась тема.
А про многопоточность или асинхронность есть несколько технологий, по этому у многих есть не понимание.
И примеры пришлось приводить на скорую руку из инета, да даже они хоть как то поясняют суть технологий.
Не кто не удосужился показать другие технологии и объяснить как они работают, один холивар.

 
Roman:

Не не, ошибаетесь, я все посмотрел буду разбираться однозначно.
Кстати вы единственный, кто дал хоть какое то верное направление благодарю, от остальных только флуд.
Тут просто многие не понимают сути темы, по этому пришлось отвечать на их вопросы. Вот и разрослась тема.
А про многопоточность или асинхронность есть несколько технологий, по этому у многих есть не понимание.
И примеры пришлось приводить на скорую руку из инета, да даже они хоть как то поясняют суть технологий.
Не кто не удосужился показать другие технологии и объяснить как они работают, один холивар.

Многопоточность - задачи работает в нескольких потоках. Могут работать на одном процессоре, все-равно будет многопоточность и переключение между ними по заканчиванию квот процессорного времени. Требуют синхронизации для доступа к разделяемым ресурсам. Чревато deadlock, race condition, ошибками в освобождении памяти и прочими "сюрпризами".

Ассинхронность - неблокируемое выполнение функций (т.е. управление сразу возвращается обратно после выхова метода), как правило на других устройствах (сетевое оборудование, устройства хранения данных, переферийные устройства и т.д.) Например, можно написать высокопроизводительный многопользовательский сервер, пользуясь только одним потоком и конечным автоматом обработки клиентских соединений. Все зависит от целей данного сервера.

В вашем случае нужно создать большое число соединений средствами WinAPI и можно проверять состояния этих соединений через WaitForMultipleObjects с таймаутом, чтобы не держать поток таймера, например.

PS.  Теоретически можно задействовать и IOCompletionPort, но он требует бОльших знаний и четкого проектирования.
 
Andrey Pogoreltsev:

Многопоточность - задачи работает в нескольких потоках. Могут работать на одном процессоре, все-равно будет многопоточность и переключение между ними по заканчиванию квот процессорного времени. Требуют синхронизации для доступа к разделяемым ресурсам. Чревато deadlock, race condition, ошибками в освобождении памяти и прочими "сюрпризами".

Неужели все так опасно? Ошибки в освобождении памяти... Но, запущенные на разных графиках советники работают в разных потоках и неожиданных сбоев вроде нет. То есть, задачи распределенные между советниками не влекут критические ошибки, а задачи распределенные между потоками внутри одного советника повлекут? Я конечно не специалист в этих вопросах, но в чем проблема перенести метод распределения задач между советниками внутрь одного советника? Возможно проблема есть, не спорю.

 
Andrey Pogoreltsev:

Многопоточность - задачи работает в нескольких потоках. Могут работать на одном процессоре, все-равно будет многопоточность и переключение между ними по заканчиванию квот процессорного времени. Требуют синхронизации для доступа к разделяемым ресурсам. Чревато deadlock, race condition, ошибками в освобождении памяти и прочими "сюрпризами".

Ассинхронность - неблокируемое выполнение функций (т.е. управление сразу возвращается обратно после выхова метода), как правило на других устройствах (сетевое оборудование, устройства хранения данных, переферийные устройства и т.д.) Например, можно написать высокопроизводительный многопользовательский сервер, пользуясь только одним потоком и конечным автоматом обработки клиентских соединений. Все зависит от целей данного сервера.

В вашем случае нужно создать большое число соединений средствами WinAPI и можно проверять состояния этих соединений через WaitForMultipleObjects с таймаутом, чтобы не держать поток таймера, например.

PS.  Теоретически можно задействовать и IOCompletionPort, но он требует бОльших знаний и четкого проектирования.

Вот, вот это разговор, неблокируемое выполнение я выполнял с помощью asyncio, но если тут написать слово корутина или калбэк, то тут такоё начнётся не понимание уж лучше промолчать ))
Сам принцип неблокирующих вызовов мне известен, но только на python, и одной ещё библиотеке Си и С++
С WinAPI ещё не работал не разу, по этому буду изучать, я не много на другую библиотеку смотрел, но разницы нет, главное синтаксис понять, а там то я понимаю что к чему ))
Но попутно в ходе беседы, предложил добавить подобный функционал в штатный mql, для возможности написания асинхронного кода из коробки.
И тут пошли непонимания, а зачем а почему. Да патамушта  )) 

Причина обращения: