Асинхронное и многопоточное программирование в MQL - страница 14
![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Неужели все так опасно? Ошибки в освобождении памяти...
Пример касается общих принципов захвата контекста устройств и выделенных ресурсов в Windows, при программировании независимых потоков разработчик обязан гарантированно освободить контекст устройства и ресурсы при требовании ОС, если разработчик использует низкоуровневые команды, он должен самостоятельно освободить все используемые ресурсы... тут в общем опять к тому моменту, что я писал - напишите один раз используя нагугленную инфу "Hello World" https://www.mql5.com/ru/forum/318593/page5#comment_12572558 и многое поймете, поймете, что 99% работы за Вас сделали системные программисты
т.е. работая в среде MQL- это за Вас сделали программисты Метаквот - обеспечили устойчивую работу терминала при неадекватной работе MQL-программы
Многопоточность - задачи работает в нескольких потоках. Могут работать на одном процессоре, все-равно будет многопоточность и переключение между ними по заканчиванию квот процессорного времени. Требуют синхронизации для доступа к разделяемым ресурсам. Чревато deadlock, race condition, ошибками в освобождении памяти и прочими "сюрпризами".
Ассинхронность - неблокируемое выполнение функций (т.е. управление сразу возвращается обратно после выхова метода), как правило на других устройствах (сетевое оборудование, устройства хранения данных, переферийные устройства и т.д.) Например, можно написать высокопроизводительный многопользовательский сервер, пользуясь только одним потоком и конечным автоматом обработки клиентских соединений. Все зависит от целей данного сервера.
В вашем случае нужно создать большое число соединений средствами WinAPI и можно проверять состояния этих соединений через WaitForMultipleObjects с таймаутом, чтобы не держать поток таймера, например.
PS. Теоретически можно задействовать и IOCompletionPort, но он требует бОльших знаний и четкого проектирования.Ну ну... вы нашли друг друга.
Спасибо за содержательный ответ ))
Ну давайте поясняйте рассказывайте, что и где есть.
И как писать асинхронный код с Eventloop штатными средствами?
Всё есть в документации.
Вы для начала её почитайте и попробуйте что-то написать.
А если не получится, можете спросить на форуме.
Пока что разговор ни о чём.
Всё есть в документации.
Вы для начала её почитайте и попробуйте что-то написать.
А если не получится, можете спросить на форуме.
Пока что разговор ни о чём.
А по вашему для чего была создана тема?
Вы расскажите нам как писать асинхронный код штатными средствами, и покажите это в документации.
Кроме асинхронной отправки заявок, покажите где Callback функции, где управляющий EventLoop, где Wait и т.д.
Уверен что вы не сможете дать на это ответ, потому что нет этого функционала для пользователей, и в доках этого нет.
Вот именно разговор не о чём, один единственный человек тут в теме Andrey Pogoreltsev, кто понимает тему общения.
Roman, 2019.07.27 09:30
А по вашему для чего была создана тема?
Вы спрашивали про многопоточность. Её нет.
Но это и не то о чём Вам нужно сейчас беспокоиться.
Roman, 2019.07.27 09:30
Вы расскажите нам как писать асинхронный код штатными средствами, и покажите это в документации.
Кроме асинхронной отправки заявок, покажите где Callback функции, где управляющий EventLoop, где Wait и т.д.
Уверен что вы не сможете дать на это ответ, потому что нет этого функционала для пользователей, и в доках этого нет.
Вот именно разговор не о чём, один единственный человек тут в теме Andrey Pogoreltsev, кто понимает тему общения.
Я могу это всё Вам показать. А смысл?
Если бы Вам это было нужно, Вы и сами бы нашли.
Вы спрашивали про многопоточность. Её нет.
многопоточность как бы есть https://www.mql5.com/ru/docs/runtime/running , т.е. хотим распараллелить задачу, открываем несколько графиков ( к сожалению я еще не пробовал пользоваться возможностями Сервисов - возможно с ними будет еще проще? ) и на них вешаем своих экспертов работающих в отдельных потоках, потом решаем задачу синхронизации и обмена данными(задачами)
я раз пять спросил ТС - зачем это нужно торговому терминалу... он не знает, ибо нет ни конкретной задачи, ни цели
я вижу применение лишь в клиент-серверных приложениях, что не свойственно задачам торгового терминала, возможно кому то удобно отправлять статистику на сервер? - в общем готовый пример (статья) уже написана https://www.mql5.com/ru/articles/5337
Исходники читаемые и статья отличного качества, исходники можно модифицировать для выполнения параллельных расчетов в несколько потоков.... осталось выяснить, что считать то будем? )))
Пример касается общих принципов захвата контекста устройств и выделенных ресурсов в Windows, при программировании независимых потоков разработчик обязан гарантированно освободить контекст устройства и ресурсы при требовании ОС, если разработчик использует низкоуровневые команды, он должен самостоятельно освободить все используемые ресурсы... тут в общем опять к тому моменту, что я писал - напишите один раз используя нагугленную инфу "Hello World" https://www.mql5.com/ru/forum/318593/page5#comment_12572558 и многое поймете, поймете, что 99% работы за Вас сделали системные программисты
т.е. работая в среде MQL- это за Вас сделали программисты Метаквот - обеспечили устойчивую работу терминала при неадекватной работе MQL-программы
Хорошо, не спорю, убедили. Правильная самостоятельная работа с потоками может быть не под силу кодерам-самоучкам и может повлечь критические ошибки. "Спички детям не игрушка". Однако, нужно как то выйти на многопоточность внутри одной программы.
Тут ведь достаточно простой логики: последовательный запуск сервисов не вызывает ошибок и каждый сервис работает в своем потоке. Значит, механизм уже настроен и отлажен. Отлично. Нужно сделать один шаг вперед: писать эти сервисы в коде советника в спец. модулях. Каждый модуль будет тем же сервисом. Далее, последовательно эти модули компилировать и одновременно запускать. Все.
По сути, ничего не меняется. Только сервисы будут писаться внутри кода совеника. Компилироваться и работать будут также. Уничтожаться при снятии советника с графика. Так получаем многопоточность эксперта.