Programmation asynchrone et multithread dans MQL - page 19

Nouveau commentaire
 
Igor Makanu:
...


Une fois encore, répondez à la question suivante : pourquoi le terminal de négociation a-t-il besoin de cela ?

...

Le terminal fonctionne-t-il avec un seul fil ? Si c'est dans plusieurs fils, est-ce pour cela que c'est nécessaire ?))

 
Реter Konow:

Il y a beaucoup de raisonnement à faire.

Hmm, c'est là que tu veux en venir avec le topicstarter ? - Vous écrivez beaucoup, mais vous ne lisez pas et ne voulez pas développer ? - Vous n'auriez pas eu le temps à mon lien, non seulement de comprendre l'article, mais même lire, voici le dernier que j'ai trouvé, voici mon code sur les "3 écrans Elder", a écrit à quelqu'un, j'ai une structure de code est toujours à ce sujet (à condition que ne sera pas d'autres modifications qui changent la logique de base, il code ... il vaut mieux ne pas se souvenir de ce que l'on peut faire à uncode initialementstructuré de façon linéaire (( ) )

void OnTick()
  {
   int takeprofit,stoploss,hstart=0; 
   double lot,h[];
   CopyClose(symbol,PeriodSecondary,hstart,HistoryCount,h);
   ENUM_CMD CMD1,CMD2,CMD3;
   CMD1 = ind1();
   CMD2 = ind2();
   CMD3 = ind3();
   if(NewBar())
     {
      DeleteOrdersLimits(Magic);
      if(CMD1==CMD_BUY && CMD2==CMD_BUY && CMD3==CMD_BUY)
        {
         CalcTakeProfitStopLoss(takeprofit,stoploss);
         lot=CalcLot(stoploss);
         if(ReversSignal)SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit); else BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);
        }
      if(CMD1==CMD_SELL && CMD2==CMD_SELL && CMD3==CMD_SELL)
        {
         CalcTakeProfitStopLoss(takeprofit,stoploss);
         lot=CalcLot(stoploss);
         if(ReversSignal)BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);else SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit);
        }
     }
  }
//+------------------------------------------------------------------+

ci-dessous seront toutes les fonctions de service, mais le code principal - le TC lui-même est le plus lisible et la logique la plus linéaire, j'ai toujours écrit ainsi, à l'université des enseignants seulement de telles sources acceptées comme remis dans le travail, sinon vous ne passerez pas ))))


Quel est l'intérêt ? - J'essaie de dire une fois de plus : le multithreading ne devrait être utilisé que s'il n'y a pas d'autre solution, personne parmi les programmeurs adéquats n'ira travailler avec des opérations asynchrones ! - ça fait mal ! ))))


un exemple sera de vous : répondez à la question pourquoi un terminal de trading en a besoin ?

 
Yuriy Asaulenko:
Oui, ils sont dans les docks, mais en réalité ils ne le sont pas. D'après ce que j'ai compris.
Volchansky a écrit à ce sujet et Renat lui a répondu.
En général, j'ai du mal à imaginer pourquoi les callbacks sont nécessaires dans un programme monofil et sans interaction avec un logiciel tiers.

Je l'ai essayé maintenant. Tout fonctionne.

Bien qu'ils ne soient d'aucune utilité pratique dans MQL.

 
Igor Makanu:

Répondez à la question suivante : pourquoi le terminal commercial a-t-il besoin de cela ?

Ils ont tous oublié les frais généraux du multithreading. Et ils ne sont pas négligeables).
 
Igor Makanu:
...


Un exemple serait le vôtre : répondez à la question "Pourquoi le terminal de trading en a-t-il besoin ?

Je vous ai déjà répondu. Vous ignorez.

1. J'ai besoin du multithreading parce que mes programmes sont beaucoup plus complexes. Je veux combiner un grand nombre de fonctions lourdes dans un seul programme. Visualisation tridimensionnelle, communication avec le serveur, interface graphique et calculs divers. Un seul fil n'est pas suffisant. Je dois donc soit diviser le programme en plusieurs parties, soit utiliser le multithreading intégré. S'il n'est pas disponible, alors je diviserai le programme en plusieurs parties.

2. le terminal est multi-threaded par lui-même. Demandez à ses développeurs pourquoi il a besoin du multithreading. Pourquoi j'ai besoin du multithreading - voir le point 1.

 

Igor Makanu

exemple de votre part : répondez à la question pourquoi le terminal de trading en a besoin ?

Le plus évident est un fil d'interface séparé, particulièrement important pour les guinées, bien que je m'en passe moi-même.

ZS : Je ne préconise pas le multithreading, si tant est que ce soit le cas.

 
Реter Konow:

Je vous ai déjà répondu. Vous ignorez.

1. J'ai besoin du multithreading parce que mes programmes sont beaucoup plus complexes. Je veux combiner un grand nombre de fonctions très lourdes dans un seul programme. Visualisation tridimensionnelle, communication avec le serveur, interface graphique et calculs divers. Un seul fil n'est pas suffisant. Je dois donc soit diviser le programme en plusieurs parties, soit utiliser le multithreading intégré. S'il n'y en a pas, alors je diviserai le programme en plusieurs parties.

2) Le terminal est lui-même multifilière. Pourquoi il a besoin du multithreading - demandez à ses développeurs. Pourquoi j'ai besoin du multithreading - voir le point 1.

Vous ignorez également ce que l'on vous dit, je l'ai déjà écrit : mouches séparées - escalopes séparées ! L'interface graphique et la stratégie de trading ne doivent pas être exécutées dans un seul code !

Dans votre sujet sur votre approche des interfaces graphiques, on vous a dit que votre code est inefficace et vous pensez qu'en lançant les fonctions dans un thread séparé, vous augmenterez les performances ? - Cela n'augmentera pas les performances, mais créera le tracas supplémentaire de tout synchroniser maintenant )))).

Je me souviens sur 4pd dans les fils de discussion sur les appareils android, les utilisateurs sont convaincus de l'efficacité de la version du firmware seulement par la quantité de mémoire libre, et tout le contraire - plus il y a de mémoire libre, plus le firmware est cool, mais malheureusement il n'y a pas de compréhension que le système d'exploitation doit utiliser efficacement toutes les ressources - y compris la mémoire, s'il y a beaucoup de mémoire libre, pas nécessairement le système d'exploitation utilise les ressources efficacement. Donc, dans votre cas, vous ne pouvez pas atteindre la performance dans un seul thread, donc vous avez besoin de plus de threads ! - Peut-être qu'il ne s'agit pasdes capacités du langage (plateforme, OS...) mais du développeur ? - Peut-être qu'il n'est pas efficace ? ;) - J'ai vérifié les interfaces graphiques de la série d'articles et de KB l'année dernière, je n'ai pas vu de décalage évident, tout fonctionne à un bon niveau. J'ai examiné le code source de ces codes, les schémas de traversée des éléments de l'interface, les approches OOP elles-mêmes - tous très similaires aux principes des graphiques dans Windows - pourquoi cela fonctionne-t-il pour eux et pas pour vous ? )))))) - Peut-être que l'approche initiale n'était pas correcte après tout, ou quevotre formation théorique est boiteuse sur les deux pattes ?

 
Igor Makanu:

Vous ignorez aussi ce qu'on vous dit, j'ai déjà écrit : mouches séparées - couperets séparés ! GUI et stratégie de trading ne doivent pas être exécutés dans le même code !

Dans votre sujet sur votre approche des interfaces graphiques, on vous a dit que votre code est inefficace et vous pensez qu'en lançant les fonctions dans un thread séparé, vous augmenterez les performances ? - Cela n'augmentera pas les performances, mais créera le tracas supplémentaire de tout synchroniser maintenant )))).

Je me souviens sur 4pd dans les fils de discussion sur les appareils android, les utilisateurs sont convaincus de l'efficacité de la version du firmware seulement par la quantité de mémoire libre, et tout le contraire - plus il y a de mémoire libre, plus le firmware est cool, mais malheureusement il n'y a pas de compréhension que le système d'exploitation doit utiliser efficacement toutes les ressources - y compris la mémoire, s'il y a beaucoup de mémoire libre, pas nécessairement le système d'exploitation utilise les ressources efficacement. Donc, dans votre cas, vous ne pouvez pas atteindre la performance dans un seul thread, donc vous avez besoin de plus de threads ! - Peut-être qu'il ne s'agit pas des capacités du langage(plateforme, OS...) mais du développeur ? - Peut-être qu'il n'est pas efficace ? ;) - J'ai vérifié les interfaces graphiques de la série d'articles et de KB l'année dernière, je n'ai pas vu de décalage évident, tout fonctionne à un bon niveau. J'ai examiné le code source de ces codes, les schémas de traversée des éléments de l'interface, les approches OOP elles-mêmes - tous très similaires aux principes des graphiques dans Windows - pourquoi cela fonctionne-t-il pour eux et pas pour vous ? )))))) - Peut-être que l'approche initiale n'était pas la bonne après tout ? ou bien la formation théorique est-elle boiteuse sur les deux pattes ?

Qu'est-ce qui vous fait penser que quelque chose est inefficace ou ne fonctionne pas pour moi ? Allez sur mon profil et voyez comment les choses fonctionnent. C'est précisément parce que les choses fonctionnent et évoluent que je suppose que le besoin de multithreading est imminent.

 
Vict:

Eh bien, le plus évident est un fil d'interface séparé, particulièrement critique pour guini, bien que je m'en passe moi-même.

ZS : Je ne préconise pas le multithreading, en fait.

Eh bien, vous n'avez pas de produits sur le Marché. Alors pourquoi faire une interface graphique en MKL alors qu'elle est facilement réalisable en C#, qui se connecte désormais facilement à MKL. Et cette interface graphique est déjà intrinsèquement exécutée dans son propre thread.

 
Igor Makanu:

void OnTick()
  {
   MqlTask obj1;
   MqlTask obj2;
   MqlTask obj3;
   MqlTask obj4;

   int takeprofit,stoploss,hstart=0; 
   double lot,h[];

   bool success = false;

   CTask *task1 = obj1.CALLBACK_FUNC(CopyClose(symbol,PeriodSecondary,hstart,HistoryCount,h));   //Выполняется асинхронно в пуле потоков
   success = task1 -> Run();
   success = task1 -> Wait(0);  
   

   ENUM_CMD CMD1,CMD2,CMD3;
   CMD1 = ind1();
   CMD2 = ind2();
   CMD3 = ind3();

   if(NewBar())
     {
      CTask *task2   = obj2.CALLBACK_FUNC(DeleteOrdersLimits(Magic));  //Выполняется асинхронно в пуле потоков
      success = task2 -> Run();
      success = task2 -> Wait(0);

      if(CMD1==CMD_BUY && CMD2==CMD_BUY && CMD3==CMD_BUY)
        {
         CTask *task3 = obj3.CALLBACK_FUNC(CalcTakeProfitStopLoss(takeprofit,stoploss));  //Выполняется асинхронно в пуле потоков
         success = task3 -> Run();
         success = task3 -> Wait(0);

         lot=CalcLot(stoploss);
         if(ReversSignal)SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit); else BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);
        }
      if(CMD1==CMD_SELL && CMD2==CMD_SELL && CMD3==CMD_SELL)
        {
         CTask *task4 = obj4.CALLBACK_FUNC(CalcTakeProfitStopLoss(takeprofit,stoploss));  //Выполняется асинхронно в пуле потоков
         success = task4 -> Run();
         success = task4 -> Wait(0);

         lot=CalcLot(stoploss);
         if(ReversSignal)BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);else SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit);
        }
     }

     delete task1;  //Очищаем ресурсы
     delete task2;
     delete task3;
     delete task4;
  }
//+------------------------------------------------------------------+


Voici un exemple d'écriture de code asynchrone linéaire dans un seul thread.
En supposant que la fonctionnalité EventLoop soit implémentée dans mql et mise en œuvre par les développeurs de ThreadPool.
L'utilisateur n'a pas besoin d'entrer dans les fils ! Les développeurs doivent s'en charger et écrire les classes correspondantes.
Le programme s'exécute dans un seul thread, tandis que les collabos réguliers non bloquants sont exécutés dans un pool de threads !
Remplacez maintenant vos fonctions simples dans les colbacks par des fonctions avec des calculs lourds ou nécessitant une concurrence.
Mega pratique et tout en parallèle ;))



Dossiers :
node.js.png  48 kb
1...121314151617181920212223242526...40
Nouveau commentaire
Raison: