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

 
Реter Konow:

Неужели все так опасно? Ошибки в освобождении памяти...

Пример касается общих принципов захвата контекста устройств и выделенных ресурсов в Windows, при программировании независимых потоков разработчик обязан гарантированно освободить контекст устройства и ресурсы при требовании ОС, если разработчик использует низкоуровневые команды, он должен самостоятельно освободить все используемые ресурсы... тут в общем опять к тому моменту, что я писал - напишите один раз используя нагугленную инфу "Hello World"  https://www.mql5.com/ru/forum/318593/page5#comment_12572558 и многое поймете, поймете, что 99% работы за Вас сделали системные программисты 

т.е. работая в среде MQL- это за Вас сделали программисты Метаквот - обеспечили устойчивую работу терминала при неадекватной работе MQL-программы

 
Andrey Pogoreltsev:

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

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

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

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

Ну ну... вы нашли друг друга.

 
А может людям витаминов каких не хватает? ...или микроэлементов...
 
Roman:

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

Всё есть в документации.

Вы для начала её почитайте и попробуйте что-то написать.

А если не получится, можете спросить на форуме.

Пока что разговор ни о чём.


 
Koldun Zloy:

Всё есть в документации.

Вы для начала её почитайте и попробуйте что-то написать.

А если не получится, можете спросить на форуме.

Пока что разговор ни о чём.


А по вашему для чего была создана тема?
Вы расскажите нам как писать асинхронный код штатными средствами, и покажите это в документации.
Кроме асинхронной отправки заявок, покажите где Callback функции, где управляющий EventLoop, где Wait и т.д.
Уверен что вы не сможете дать на это ответ, потому что нет этого функционала для пользователей, и в доках этого нет.
Вот именно разговор не о чём, один единственный человек тут в теме Andrey Pogoreltsev, кто понимает тему общения.

 
Евентлуп! Есть у кого-нибудь Евентлуп? Здесь человеку плохо без Евентлупа! Ну дайте же Евентлуп кто-нибудь! 
 

Roman, 2019.07.27 09:30

А по вашему для чего была создана тема?


Вы спрашивали про многопоточность. Её нет.

Но это и не то о чём Вам нужно сейчас беспокоиться.

Roman, 2019.07.27 09:30

Вы расскажите нам как писать асинхронный код штатными средствами, и покажите это в документации.
Кроме асинхронной отправки заявок, покажите где Callback функции, где управляющий EventLoop, где Wait и т.д.
Уверен что вы не сможете дать на это ответ, потому что нет этого функционала для пользователей, и в доках этого нет.
Вот именно разговор не о чём, один единственный человек тут в теме  Andrey Pogoreltsev, кто понимает тему общения.

Я могу это всё Вам показать. А смысл?

Если бы Вам это было нужно, Вы и сами бы нашли.

Очевидно, что Вы ни документацию ни статьи не читали.
 
Koldun Zloy:

Вы спрашивали про многопоточность. Её нет.

многопоточность как бы есть https://www.mql5.com/ru/docs/runtime/running , т.е. хотим распараллелить задачу, открываем несколько графиков ( к сожалению я еще не пробовал пользоваться возможностями Сервисов - возможно с ними будет еще проще? ) и на них вешаем своих экспертов работающих в отдельных потоках, потом решаем задачу синхронизации и обмена данными(задачами)

я раз пять спросил ТС - зачем это нужно торговому терминалу... он не знает, ибо нет ни конкретной задачи, ни цели

я вижу применение лишь в клиент-серверных приложениях, что не свойственно задачам торгового терминала, возможно кому то удобно отправлять статистику на сервер? - в общем готовый пример (статья) уже написана  https://www.mql5.com/ru/articles/5337

Исходники читаемые и   статья отличного качества, исходники можно модифицировать для выполнения параллельных расчетов в несколько потоков.... осталось выяснить, что считать то будем? )))

 
Igor Makanu:

Пример касается общих принципов захвата контекста устройств и выделенных ресурсов в Windows, при программировании независимых потоков разработчик обязан гарантированно освободить контекст устройства и ресурсы при требовании ОС, если разработчик использует низкоуровневые команды, он должен самостоятельно освободить все используемые ресурсы... тут в общем опять к тому моменту, что я писал - напишите один раз используя нагугленную инфу "Hello World"  https://www.mql5.com/ru/forum/318593/page5#comment_12572558 и многое поймете, поймете, что 99% работы за Вас сделали системные программисты 

т.е. работая в среде MQL- это за Вас сделали программисты Метаквот - обеспечили устойчивую работу терминала при неадекватной работе MQL-программы

Хорошо, не спорю, убедили. Правильная самостоятельная работа с потоками может быть не под силу кодерам-самоучкам и может повлечь критические ошибки. "Спички детям не игрушка". Однако, нужно как то выйти на многопоточность внутри одной программы.

Тут ведь достаточно простой логики: последовательный запуск сервисов не вызывает ошибок и каждый сервис работает в своем потоке. Значит, механизм уже настроен и отлажен. Отлично. Нужно сделать один шаг вперед: писать эти сервисы в коде советника в спец. модулях. Каждый модуль будет тем же сервисом. Далее, последовательно эти модули компилировать и одновременно запускать. Все.

По сути, ничего не меняется. Только сервисы будут писаться внутри кода совеника. Компилироваться и работать будут также. Уничтожаться при снятии советника с графика. Так получаем многопоточность эксперта.

 
Можно еще проще. Советник сам загружает нужные сервисы, которые пишутся отдельно. При снятии с графика, останавливает их. Всего то нужно добавить запуск сервисов из советника. А внутреннее взаимодействие между потоками - задача программиста. Решается с помощью ресурсов.
Причина обращения: