Этого делать не будем - каждая MQL5 программа принципиально однопоточная.
Подумайте сами над засадами и глобальными последствиями. Если сильно хочется использовать все ядра, то применяйте DLL.

Этого делать не будем - каждая MQL5 программа принципиально однопоточная.
Подумайте сами над засадами и глобальными последствиями. Если сильно хочется использовать все ядра, то применяйте DLL.
"Если посмотреть на тело сверху то снизу ничего видно не будет" :о), а посему я видя только верхнюю часть языка ни о каких засадах не догадываюсь.
Ваш ответ понял что этого не будет, но может поясните о чём речь, о каких засадах? если вопрос сводится к сигналу завершения расчёта так пускай об этом программисты заботятся через флаги завершения.
Синхронизация и совместный доступ.
Святая наивность...
Святая наивность...
В MQL5 по сути, почти все синхронизировано, одновременный запрос двух индикаторов к буферам/глобальным переменным/торговым операциям и т.п. не вызывают рандомные затирания памяти.
Значит подводных камней не так то много. Синхронизировать общий доступ к массивам/переменным/классам.
В Java же как-то сделали, все синхронно, использование синхронных методов нужно для пользовательских нужд, например запросов в бд, и т.п.
Значит можно же, думаю, MQ, обсудят, подумают и максимум в MQL6 точно сделают, т.к. частота процессоров упирается в потолок, а вот их кол-во по сути не ограниченно.
И считать в одном потоке, как то старомодно :)

- www.mql5.com
Есть такая открытая штука - OpenCL. Возможно компилятор MQL6 будет поддерживать этот фреймворк?
OpenCL (от англ. Open Computing Language — русск. открытый язык вычислений) — фреймворк для написания компьютерных программ, связанных с параллельными вычислениями на различных графических (англ. GPU) и центральных процессорах (англ. CPU). В фреймворк OpenCL входят язык программирования, который базируется на стандарте C99, и интерфейс программирования приложений (англ. API). OpenCL обеспечивает параллелизм на уровне инструкций и на уровне данных и является реализацией техники GPGPU. OpenCL является полностью открытым стандартом, его использование не облагается лицензионными отчислениями.

- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Сейчас функции создания и уничтожения потока делят между собой чарт и индикатор.
Для того чтоб написать многопоточное приложение программист ухищряется в комбинировании открытии чарта и запуска в нём индикатора с уникальными параметрами. Отсюда такой повышенный интерес к модернизации индикаторов, добавлении им новых свойств не предусмотренных концепцией MQ.
А почему бы не дать в руки программисту инструмент управления потоками?
Например оператор определяющий что каждый экземпляр данного класса будет работать в собственном потоке.
В таком случае исчезнет необходимость в ухищрениях и каждый программист сможет использовать что ему необходимо. Если вам нужен рисуемый индикатор то создавайте индикатор, если не рисуемый (а лишь рассчитывающий значения) то пожалуйте к управлению потоками, пишите класс, и подключайте его к советнику.
Высказывайтесь кто как думает? особенно интересно мнение разработчиков, насколько это сложно реализовать?