Programmazione asincrona e multithread in MQL - pagina 19

Nuovo commento
 
Igor Makanu:
...


Ancora una volta, rispondete alla domanda: perché il terminale di trading ha bisogno di questo?

...

Il terminale funziona con un solo filo? Se è in più thread, è per questo che è necessario?))

 
Реter Konow:

Ci sono molti ragionamenti da fare.

Hmm, è lì che vai anche tu? - Scrivi molto, ma non leggi e non vuoi sviluppare? - Non avresti avuto tempo al mio link, non solo per capire l'articolo, ma anche leggere, ecco l'ultimo che ho trovato, ecco il mio codice sul "3 schermi Elder", ha scritto a qualcuno, ho una struttura di codice è sempre su questo (a condizione che non sarà ulteriori modifiche che cambiano la logica di base, ci codice ... meglio non ricordare cosa può essere fatto alcodice strutturato inizialmente lineare (( ) )

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);
        }
     }
  }
//+------------------------------------------------------------------+

di seguito saranno tutte le funzioni di servizio, ma il codice principale - il TC stesso è il più leggibile e la logica più lineare, ho sempre scritto così, ai professori universitari solo tali fonti accettate come lavoro consegnato, altrimenti non si passa ))))


qual è il punto? - Sto cercando di dire ancora una volta: il multi-threading dovrebbe essere usato solo se non c'è altra soluzione, nessuno dei programmatori adeguati andrà semplicemente a lavorare con operazioni asincrone! - fa male! ))))


un esempio sarà da voi: rispondete alla domanda perché un terminale di trading ne ha bisogno?

 
Yuriy Asaulenko:
Sì, sono nel porto, ma in realtà non lo sono. Per quanto ho capito.
Volchansky ha scritto su questo e Renat gli ha risposto.
In generale, trovo difficile immaginare perché le callback siano necessarie in un programma single-threaded senza interazione con software di terze parti.

L'ho provato ora. Tutto funziona.

Anche se non sono di alcuna utilità pratica nel MQL.

 
Igor Makanu:

Rispondere alla domanda: perché il terminale di trading ha bisogno di questo?

Hanno tutti dimenticato l'overhead del multithreading. E non sono insignificanti).
 
Igor Makanu:
...


Un esempio potrebbe essere da parte vostra: rispondete alla domanda: perché il terminale di trading ne ha bisogno?

Vi ho già risposto. Stai ignorando.

1. Ho bisogno del multithreading perché i miei programmi sono molto più complessi. Voglio combinare molte funzioni pesanti in un solo programma. Visualizzazione tridimensionale, comunicazione server, GUI e vari calcoli. Un solo filo non è sufficiente. Quindi, devo dividere il programma in parti o usare il multithreading integrato. Se non è disponibile, allora dividerò il programma in parti.

2. il terminale è multi-threaded da solo. Chiedete ai suoi sviluppatori perché ha bisogno del multithreading. Perché ho bisogno del multithreading - vedi punto 1.

 

Igor Makanu

esempio da voi: rispondete alla domanda: perché il terminale di trading ne ha bisogno?

Beh, il più ovvio è un filo di interfaccia separato, particolarmente critico per le ghinee, anche se io stesso ne faccio a meno.

ZS: Non sostengo il multithreading, semmai.

 
Реter Konow:

Ti ho già risposto. Stai ignorando.

1. Ho bisogno del multithreading perché i miei programmi sono molto più complessi. Voglio combinare molte funzioni molto pesanti in un solo programma. Visualizzazione tridimensionale, comunicazione server, GUI e vari calcoli. Un solo filo non è sufficiente. Quindi, devo dividere il programma in parti o usare il multithreading nativo. Se non c'è, allora divido il programma in parti.

2) Il terminale è multi-threaded di per sé. Perché ha bisogno del multi-threading - chiedete ai suoi sviluppatori. Perché ho bisogno del multi-threading - vedi punto 1.

Ignorate anche quello che vi viene detto, l'ho già scritto: mosche separate - cotolette separate!

Nel tuo topic sul tuo approccio alle interfacce grafiche, ti è stato detto che il tuo codice è inefficiente e pensi che buttando le funzioni in un thread separato aumenterai le prestazioni? - Non aumenterà le prestazioni, ma creerà il fastidio aggiuntivo di sincronizzare tutto ora ))))

Ricordando su 4pd nei thread su android - dispositivi, gli utenti sono convinti dell'efficacia della versione del firmware solo dalla quantità di memoria libera, e piuttosto il contrario - più memoria libera, più fresco è il firmware, ma purtroppo non c'è la comprensione che il sistema operativo deve utilizzare in modo efficiente tutte le risorse - compresa la memoria, se c'è molta memoria libera, non necessariamente il sistema operativo utilizza le risorse in modo efficiente. Quindi, nel vostro caso, non potete ottenere prestazioni in un solo thread, quindi avete bisogno di più thread! - Forse non si tratta dellecapacità del linguaggio (piattaforma, OS...) ma dello sviluppatore? - Forse non è efficiente? ;) - Ho controllato le GUI della serie di articoli e in KB dell'anno scorso, non ho visto alcun lag evidente, tutto funziona a un buon livello. Ho guardato il codice sorgente di quei codici, gli schemi di attraversamento degli elementi dell'interfaccia, gli stessi approcci OOP - tutti molto simili ai principi della grafica in Windows - perché funziona per loro e non per voi? )))))) - Forse l'approccio iniziale non era corretto dopo tutto, o iltuo background teorico è zoppo su entrambe le zampe?

 
Igor Makanu:

Ignorate anche quello che vi è scritto, l'ho già scritto: mosche separate - cotolette separate! GUI e strategia di trading non dovrebbero essere eseguite in un solo codice!

Nel tuo topic sul tuo approccio alle interfacce grafiche, ti è stato detto che il tuo codice è inefficiente e pensi che buttando le funzioni in un thread separato aumenterai le prestazioni? - Non aumenterà le prestazioni, ma creerà il fastidio aggiuntivo di sincronizzare tutto ora ))))

Ricordando su 4pd nei thread su android - dispositivi, gli utenti sono convinti dell'efficacia della versione del firmware solo dalla quantità di memoria libera, e piuttosto il contrario - più memoria libera, più fresco è il firmware, ma purtroppo non c'è la comprensione che il sistema operativo deve utilizzare in modo efficiente tutte le risorse - compresa la memoria, se c'è molta memoria libera, non necessariamente il sistema operativo utilizza le risorse in modo efficiente. Quindi, nel vostro caso, non potete ottenere prestazioni in un solo thread, quindi avete bisogno di più thread! - Forse non si tratta delle capacità del linguaggio(piattaforma, OS...) ma dello sviluppatore? - Forse non è efficiente? ;) - Ho controllato le GUI della serie di articoli e in KB dell'anno scorso, non ho visto alcun lag evidente, tutto funziona a un buon livello. Ho guardato il codice sorgente di quei codici, gli schemi di attraversamento degli elementi dell'interfaccia, gli stessi approcci OOP - tutti molto simili ai principi della grafica in Windows - perché funziona per loro e non per voi? )))))) - forse l'approccio iniziale non era giusto dopo tutto, o il tuo background teorico è zoppo su entrambe le zampe?

Cosa ti fa pensare che qualcosa sia inefficiente o non funzioni per me? Vai al mio profilo e vedi come funzionano le cose. È proprio perché le cose funzionano e si evolvono che presumo che la necessità del multithreading sia imminente.

 
Vict:

Beh, il più ovvio è un filo di interfaccia separato, particolarmente critico per i guini, anche se io stesso ne faccio a meno.

ZS: Non sto sostenendo il multithreading, semmai.

Beh, non avete prodotti nel Marketplace. Allora perché fare una GUI in MKL quando è facilmente realizzabile in C#, che ora si collega facilmente a MKL. E quella GUI è già intrinsecamente in esecuzione in un proprio 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;
  }
//+------------------------------------------------------------------+


Ecco un esempio di scrittura di codice lineare asincrono in un thread.
Supponendo che la funzionalità EventLoop sia implementata in mql e realizzata dagli sviluppatori di ThreadPool.
L'utente non ha bisogno di entrare nei fili! Gli sviluppatori dovrebbero occuparsene e scrivere le classi corrispondenti.
Il programma viene eseguito in un singolo thread, mentre i normali collage non bloccanti vengono eseguiti in un pool di thread!
Ora sostituite le vostre semplici funzioni in colback con funzioni con calcoli pesanti o che richiedono concorrenza.
Mega conveniente e tutto in parallelo ))



File:
node.js.png  48 kb
1...121314151617181920212223242526...40
Nuovo commento