Programmation asynchrone et multithread dans MQL - page 15
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Vous avez posé une question sur le multithreading. Ce n'est pas le cas.
Mais ce n'est pas non plus ce dont vous devez vous soucier pour l'instant.
Je peux vous montrer tout ça. Quel est l'intérêt ?
Si tu en avais besoin, tu le trouverais toi-même.
C'est la réponse attendue d'un homme qui n'a rien à dire sur le sujet, mais qui doit répondre.
J'ai lu des articles sur le multithreading sur 1-2 pages et j'ai essayé de le traduire en communication asynchrone.
Si vous parlez de l'article sur le web-breakfast asynchrone, je ne l'ai pas approfondi, mais ce n'est pas de la programmation asynchrone à part entière.
Il s'agit d'une autre invention d'un homme intelligent qui a réussi à utiliser des béquilles, à défaut d'une fonctionnalité régulière.
Vous avez posé une question sur le multithreading. Ce n'est pas le cas.
...
Non, pas du tout. Il n'a pas besoin du multithreading, il sait juste comment faire de manière asynchrone sans lui.
Le multithreading est commehttps://www.mql5.com/ru/docs/runtime/running , c'est-à-dire que nous voulons paralléliser la tâche, ouvrir plusieurs graphes (malheureusement, je n'ai pas encore essayé d'utiliser les fonctions de services - peut-être que ce sera encore plus facile avec eux ? ) et y attacher nos EA travaillant dans des threads séparés, puis résoudre le problème de la synchronisation et de l'échange de données (tâches).
J'ai demandé cinq fois au TS - pourquoi le terminal de trading en a besoin... il ne sait pas, parce qu'il n'y a pas de tâche ou de but spécifique
Je peux voir l'utilisation dans des applications client-serveur qui n'est pas typique pour le terminal de trading, peut-être est-il pratique pour quelqu'un d'envoyer des statistiques au serveur ? - Eh bien, j'ai déjà écrit un exemple (article) prêt à l'emploi https://www.mql5.com/ru/articles/5337.
Les sources sont lisibles et l'article est d'excellente qualité ; les sources peuvent être modifiées pour effectuer des calculs parallèles dans plusieurs threads..... Maintenant, que devons-nous calculer ? )))
Igor, je vous ai déjà donné beaucoup d'exemples et vous n'arrivez toujours pas à comprendre pourquoi l'asynchronie est nécessaire)).
) Et il ne s'agit pas seulement d'applications client-serveur et vous essayez encore de savoir ce qu'il faut compter ;))
Je vous ai déjà écrit, vous essayez de construire un NS, n'avez-vous pas besoin d'asynchrone dans ce cas ?
Mais vous construisez NS sur des fonctions d'activation simples, donc vous n'avez pas été confronté au manque de concurrence.
Mais lorsque vous commencerez à construire des modèles globaux de NS, vous comprendrez la beauté de l'asynchronie.
Et c'est un exemple à votre avantage, mais vous vous obstinez à ne pas le comprendre.
Comprenez que l'asynchronie n'est pas seulement nécessaire pour les appels réseau.
Les autres utilisateurs auront d'autres idées et tâches, chacun a des objectifs différents de l'approche asynchrone, il n'est pas correct d'affirmer quelque chose sans ambiguïté.
C'était la réponse attendue d'une personne qui n'a rien à dire sur le sujet mais qui doit répondre.
A propos du multithreading il était clair sur 1-2 pages qu'il n'existe pas, donc j'ai essayé de traduire la discussion sur l'asynchrone, hélas, ça n'a pas marché.
Si vous voulez parler de l'article sur le web-breakfast asynchrone, eh bien, je n'ai pas encore approfondi cet article, mais ce n'est pas de la programmation asynchrone à part entière.
Il s'agit d'une autre invention d'un homme intelligent qui a réussi à se servir de béquilles, à défaut d'une fonctionnalité régulière.
Et si je vous dis que vous avez raison et que tout cela manque vraiment dans MQL.
Alors vous direz que je vous comprends ? Mais cela ne vous servira à rien.
Je vous dis quelque chose qui peut vous aider. Mais vous devrez travailler dur.
Non, ce n'est pas du tout ça. Il n'a pas besoin du multithreading, il sait juste comment faire de manière asynchrone sans lui.
Exactement sur les appels non bloquants, de manière asynchrone dans un seul thread !
Igor, vous avez déjà donné beaucoup d'exemples, mais vous n'arrivez toujours pas à comprendre pourquoi l'asynchronie est nécessaire ;))
...
Ça vous fait plaisir de penser que les gens qui ne le sont pas sont des idiots ?
Exactement sur les appels non bloquants, de manière asynchrone dans un seul thread !
... Et depuis le troisième jour maintenant, vous ne cessez de démontrer que c'est vous.
Et si je vous dis que vous avez raison et que tout cela manque vraiment dans MQL.
Alors vous direz que je vous comprends ? Mais cela ne vous servira à rien.
Je vous dis quelque chose qui peut vous aider. Mais vous devrez travailler dur.
Merci de votre compréhension ;)))
Oui cet article est très bien, pour une solution unique, à y réfléchir, peut-être que l'on peut encore tirer parti de cette approche.
Dans mon cas, j'ai décidé de l'orientation de ma tâche, grâce à Andrew pour ses conseils.
Mais la question s'est transformée en une question globale))
Ai-je besoin des méthodes asynchrones standard du langage mql ?
Pas les threads, à savoir les appels qui ne sont pas bloqués par la fonction colback, contrôlée par EventLoop.
Ce qui permet d'atteindre l'asynchronie dans un seul thread.