Programmation asynchrone et multithread dans MQL - page 8

 
Dmitry Fedoseev:

Il semble que la différence particulière entre l'asynchronie et le multithreading provienne du même domaine que le problème de la différence entre les pointeurs et les références qui tourmente certaines personnes.

L'asynchronie est mise en œuvre par le biais d'un thread séparé et il n'est pas très important que ce processus soit fourni par le processeur ou tout autre dispositif. La création d'un processus implique son asynchronisme car il existe en parallèle.

L'asynchronie est mise en œuvre dans le même fil d'exécution du programme, par le biais d'EventLoop, mais la façon dont EventLoop est mis en œuvre est la prérogative des développeurs, comment l'implémenter.
Les mêmes gestionnaires standard dans mql, par exemple OnTimer fonctionne dans sa propre boucle, et c'est une sorte d'EventLoop,
Si vous souhaitez créer un gestionnaire distinct pour les méthodes asynchrones, toutes les tâches seront parfaitement exécutées dans une boucle asynchrone.

 
Roman:

L'asynchronie est mise en œuvre dans le même fil d'exécution du programme, par le biais d'EventLoop, mais la manière dont EventLoop est mis en œuvre est la prérogative des développeurs.
Les mêmes gestionnaires standard dans mql, par exemple OnTimer fonctionne dans sa propre boucle, et c'est une sorte d'EventLoop,
Si vous souhaitez créer un gestionnaire distinct pour les méthodes asynchrones, toutes les tâches seront parfaitement exécutées dans une boucle asynchrone.

Excusez-moi, où l'asynchronie est-elle implémentée via EventLoop ?

Vous pouvez faire quelque chose comme EventLoop vous-même maintenant, les développeurs de terminaux ne sont pas du tout nécessaires ici.

 
Dmitry Fedoseev:

Excusez-moi, où l'asynchronie est-elle implémentée via EventLoop ?

Vous pouvez faire quelque chose comme EventLoop vous-même maintenant, les développeurs de terminaux ne sont pas du tout nécessaires ici.

EventLoop est implémenté dans asyncio, et je pense que le même principe est utilisé dans d'autres bibliothèques asynchrones.
Même WinAPI, si je comprends bien, utilise le principe de l'événement pour l'asynchronie.
À l'heure actuelle, nous ne pouvons pas mettre en œuvre un mode asynchrone complet à l'aide d'outils standard,
La raison en est que le gestionnaire OnTimer, par exemple, ne contrôle pas l'exécution de la tâche et exécute plutôt la boucle de manière séquentielle.
En d'autres termes, le gestionnaire ne dispose pas du mécanisme d'exécution asynchrone des tâches.

 

Tout le monde google le concept d'impasse !

Dans MQL5, l'ajout de threads interrompra le système de test et tout le nuage d'agents tombera en panne.

Une solution de contournement de cette limitation est possible avec les DLL. Si vous ne voulez pas apprendre C#, C++, C, Python - c'est votre problème. Dans le monde d'aujourd'hui, un programmeur doit connaître plusieurs langages pour choisir correctement un outil pour une tâche particulière.

Ceux qui connaissent le 1C ne sont pas considérés comme des programmeurs. Il en va de même pour MQL5.

 
Roffild:

Tout le monde google le concept d'impasse !

Dans MQL5, l'ajout de threads va casser le système de test et tout le nuage d'agents va se bloquer.

Une solution de contournement de cette limitation est possible avec les DLL. Si vous ne voulez pas apprendre C#, C++, C, Python - c'est votre problème. Dans le monde d'aujourd'hui, un programmeur doit connaître plusieurs langages pour choisir correctement un outil pour une tâche particulière.

Ceux qui connaissent le 1C ne sont pas considérés comme des programmeurs. Il en va de même pour MQL5.

Si un programme MQL multi-threads brise le système de test, quelle différence cela fait-il, qu'il soit attaché par une DLL ou une DLL normale ? Dans tous les cas, vous devrez choisir entre les tests et le multithreading. Mais il est préférable de choisir au sein de MQL, car l'intégrité est un atout pour le programme.
 
Roffild:

Tout le monde google le concept d'impasse !

Dans MQL5, l'ajout de threads va casser le système de test et tout le nuage d'agents va se bloquer.

Une solution de contournement de cette limitation est possible avec les DLL. Si vous ne voulez pas apprendre C#, C++, C, Python - c'est votre problème. Dans le monde d'aujourd'hui, un programmeur doit connaître plusieurs langages pour choisir correctement un outil pour une tâche particulière.

Ceux qui connaissent le 1C ne sont pas considérés comme des programmeurs. Il en va de même pour MQL5.

Lors des tests, toutes les tâches peuvent être résolues une par une et les résultats peuvent être renvoyés à certains moments (vous pouvez attendre dans le testeur). Non seulement vous pouvez, mais vous devez, afin que cela corresponde à la réalité.

Je me demande ce que les programmeurs de 1C en pensent ? L'opinion d'autrui les intéresse-t-elle ?

 
Реter Konow:
Si un programme MQL multi-threads brise le système de test, quelle différence cela fait-il, qu'il soit attaché par une DLL ou une DLL normale ? Dans tous les cas, vous devrez choisir entre les tests et le multithreading. Mais il est préférable de choisir au sein de MQL, car l'intégrité est un atout pour le programme.
En général, le multithreading est nécessaire en mode normal. Les tests fonctionnent toujours avec un petit module de programme - une stratégie, et toutes les autres capacités du programme ont un reste. Visualisation, etc. Ainsi, pendant le test, seul le thread où se trouve le module de stratégie sera en cours d'exécution. Dans le testeur, certaines fonctions et événements réguliers sont désactivés, alors faites en sorte que les fils soient également désactivés.
 
Реter Konow:
Si un programme MQL multithread casse le système de test, quelle différence cela fait-il de savoir comment il est attaché, via une DLL ou une DLL normale ? Dans tous les cas, vous devrez choisir entre les tests et le multithreading. Mais il est préférable de choisir au sein de MQL, car l'intégrité est un atout pour le programme.

Il y a une différence. Les DLL ne sont pas autorisées dans le nuage. Et les DLL elles-mêmes sont désactivées dès le départ. En autorisant les DLL, vous renoncez à la responsabilité d'une exécution sûre du code.

 
Roman:

EventLoop est implémenté dans asyncio, et je crois que le même principe est utilisé dans d'autres bibliothèques asynchrones.
...

Les autres bibliothèques asynchrones n'utilisent pas ce principe.

 
Dmitry Fedoseev:

Les autres bibliothèques asynchrones n'utilisent pas ce principe.

C'était juste une supposition, je n'ai pas vérifié où il est utilisé ailleurs.
J'ai cherché sur Google quels langages utilisent EventLoop, c'est Py, JS, Qt, probablement d'autres.
Le problème n'est pas de savoir où il est appliqué, mais bien de savoir comment utiliser la technologie elle-même sans utiliser de fils.
Alors pourquoi ne pas emprunter la technologie et implémenter en mql votre EventLoop ?