MT5 et la vitesse en action - page 74
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
Pouvez-vous développer ces raisons objectives ?
Freins injustifiés
Si les gens ici ne comprennent pas ce qui est écrit, je suis désolé, ce n'est pas mon problème, c'est le problème de ceux qui ne fument pas le sujet de conversation.
Non. C'est ton problème. C'est vous qui l'avez évoqué sans en comprendre le sens et les implications.
Ce sujet a été abordé à de nombreuses reprises ici depuis plus de 10 ans.
Ralentissements déraisonnables
Donc un gestionnaire de tâches fonctionnant dans une boucle d'événements, dispersant de multiples tâches (égales au nombre de gestionnaires) provoquera des ralentissements ?
Après tout, il n'y a pas tant de maîtres-chiens que ça, juste quelques-uns. Il suffit de les disperser parmi les tâches et de les libérer dans leur propre boucle d'événements.
Dans le même temps, contrôlez le drapeau d'exécution du gestionnaire. Le gestionnaire a fonctionné, a réinitialisé le drapeau, et ainsi de suite.
D'une certaine manière, je ne crois pas aux ralentissements, nous ne traitons pas tous les événements, mais seulement le nombre égal de gestionnaires.
Et les gestionnaires eux-mêmes ont leurs propres événements.
Donc un gestionnaire de tâches fonctionnant dans une boucle d'événements, dispersant de multiples tâches (égales au nombre de gestionnaires) provoquera des ralentissements ?
Il n'y a pas tant de maîtres-chiens que ça, juste quelques-uns. Il suffit de les disperser parmi les tâches et de les libérer dans leur propre boucle d'événements.
Ce faisant, vous contrôlez le drapeau d'exécution du gestionnaire. Exécuter le gestionnaire, réinitialiser l'indicateur, et ainsi de suite.
Il ne reviendra pas sur les freins, ce ne sont pas tous les événements qui sont traités, mais seulement le nombre égal de gestionnaires.
Les gestionnaires ont leurs propres événements.
Là où il y a un écrivain, le lecteur doit attendre. Jusqu'à ce que l'écrivain écrive.
S'il y a plus d'un lecteur, il doit négocier ses propres variables. Pendant qu'une incarnation modifie le contenu de la variable, les autres attendent. Même s'il n'y a pas d'autres incarnations à ce moment-là, le verrouillage de la ressource se fait toujours au cœur du système, une opération coûteuse. Le plaisir commence lorsque toutes les incarnations s'attaquent à l'environnement commercial. Dieu interdit qu'ils commencent à échanger en même temps.
En somme, les jeunes n'écoutent pas ce qu'on leur dit. De façon répétée. Avec des exemples. Avec des explications. Pendant plus de dix années consécutives.
Non. C'est ton problème. C'est vous qui l'avez évoqué sans en comprendre le sens et les conséquences.
Ce sujet a été abordé à de nombreuses reprises ici depuis plus de 10 ans.
Tout ce que j'ai vu de la part des opposants, ce sont des attaques inadéquates plutôt qu'une discussion constructive.
Si vous étiez intervenu en temps utile pour clarifier la situation, il n'y aurait pas eu de questions inutiles.
Et quand un développeur garde le silence, on ne sait pas quoi penser. Beaucoup de choses ont changé dans le monde de la technologie en 10 ans.
Bon, maintenant que je comprends que vous m'avez entendu, j'espère que vous allez réfléchir à nouveau à cette question. Peut-être que vous pouvez le résoudre, ce serait vraiment cool.
Je n'ai vu que des attaques inadéquates de la part de mes adversaires, pas de discussion constructive.
Si vous étiez intervenu en temps utile pour clarifier les choses, il n'y aurait pas eu de questions inutiles.
Et quand un développeur est silencieux, vous ne savez pas quoi penser. Beaucoup de choses ont changé dans le monde de la technologie en 10 ans.
Bon, maintenant que je comprends que vous m'avez entendu, j'espère que vous allez réfléchir à nouveau à cette question. On peut peut-être s'arranger, ce serait vraiment cool.
Les attaques inadéquates sont, "chut, encore ?"
Toutes les réponses étaient normales. Les attaques ne venaient que de moi. Je suis désolé si je vous ai offensé.
Et les gars ont répondu de manière appropriée.
Là où il y a un écrivain, le lecteur doit attendre. Jusqu'à ce que l'écrivain écrive.
S'il y a plus d'un lecteur, le lecteur doit négocier ses propres variables.
Pendant qu'une incarnation modifie le contenu de la variable, les autres attendent.
Même s'il n'y a pas d'autres incarnations à ce moment-là, le verrouillage de la ressource se fait toujours au cœur du système, une opération coûteuse.
Le plaisir commence lorsque toutes les incarnations s'attaquent à l'environnement commercial. Dieu interdit qu'ils commencent à échanger en même temps.
En somme, les jeunes n'écoutent pas ce qu'on leur dit. De façon répétée. Avec des exemples. Avec des explications. Pendant plus de 10 ans d'affilée.
Si je comprends bien ce qui précède, le problème est le synchronisme auteur/lecteur lui-même, qui peut être coûteux.
Pas de synchronisation, pas de problème. Hmmm, succinctement sage, du côté de l'optimisation. Merci pour la clarification oncle Slav ;))
S'il vous plaît ne me le reprochez pas non plus. Je ne suis pas un magicien, je ne fais qu'apprendre ;))
Je ne comprends pas, dans les systèmes en temps réel, tout fonctionne en mode multitâche, et la procédure de synchronisation est l'outil principal.
Donc, l'OSRT est aussi un système de freinage ? Ça ne semble pas logique. Mais il y a aussi les délais, la latence et la gigue.
Et que pouvez-vous dire du modèle objet, il y a une course ici ? Ou quelles peuvent être les conséquences d'une telle approche ?
https://www.mql5.com/ru/code/31306
Ou quelles pourraient être les conséquences d'une telle approche ?
https://www.mql5.com/ru/code/31306
Et qu'est-ce que ça peut bien valoir ?
Bonjour Nikolaï. Eh bien, c'est vrai.
Mais cela ne va-t-il pas provoquer le même problème qu'avec la synchronisation dont parle Slava, c'est-à-dire un freinage déraisonnable.
Ou peut-être n'y a-t-il pas de problème ? )) Peut-être est-il plus facile de ne pas utiliser de modèle asynchrone que de le synchroniser avec des priorités ? ))
Bonjour Nikolaï. C'est vrai.
Mais n'y aura-t-il pas le même problème qu'avec la synchronisation, dont parle Slava, c'est-à-dire des freins déraisonnables.
Ou peut-être n'y a-t-il pas de problème ? )) Peut-être est-il plus facile de ne pas utiliser de modèle asynchrone que de le synchroniser avec des priorités ? ))
Je ne suis pas un expert. en graphiques. L'importance est déterminée par la dépendance du début des autres tâches par rapport à la fin de la tâche en cours. les autres critères sont secondaires. mais il y a aussi le temps d'exécution de la tâche. et c'est aussi le plus important parmi le peer-to-peer. En général, c'est difficile et le plus triste, c'est que l'algorithme de priorisation ne peut pas être modifié à la volée. Du côté positif, j'aimerais obtenir des éclaircissements de la part des développeurs avant de poser des questions. C'est difficile, mais c'est le bon objectif pour le développement de l'environnement.