Programmazione asincrona e multithread in MQL - pagina 24

Nuovo commento
 
Roman:

Non ho studiato per essere un programmatore, sto imparando tutto da solo, quindi non cacciatemi via ))

Nemmeno io. Ho una professione diversa. La programmazione è solo uno strumento, come un martello).

Creare DLL per MKL - c'è una DLL assolutamente standard, nessuna caratteristica speciale. Il resto è puro C++, o puro C# se volete.

Insegnare C++ o Sharp è al di là di me, ma ci sono vagonate di letteratura, a qualsiasi livello.

C'è un articolo su MKL sulla creazione di una semplice DLL, non posso dire nulla sul fatto che sia informativo. Sì, e Google per aiutare con la domanda - creazione di DLL C++.

A proposito, parlando del punto di ingresso e così via. In Visual Studio si crea un progetto DLL e tutto ciò di cui avete bisogno è creato da voi, basta non toccarlo con le mani). E le funzioni di interazione, i fili, ecc. sono a vostra discrezione. - dipendono da voi. Questo è C++, non ci sono queste caratteristiche associate specificamente alla DLL.

ZZY Il modo migliore per imparare qualcosa è risolvere un compito specifico. Non è stato nemmeno inventato da me).

 
Yuriy Asaulenko:

Nemmeno io. Ho una professione diversa. La programmazione è solo uno strumento, come un martello).

Creare dll per MKL - assolutamente dll standard lì, nessuna caratteristica speciale. Il resto è puro C++, o puro C# se volete.

Insegnare C++ o Sharp è al di là di me, ma ci sono vagonate di letteratura, a qualsiasi livello.

C'è un articolo su MKL sulla creazione di una semplice DLL, non posso dire nulla sul fatto che sia informativo. Sì, e Google per aiutare con la domanda - creazione di DLL C++.

A proposito, parlando del punto di ingresso e così via. In Visual Studio si crea un progetto DLL e tutto ciò di cui avete bisogno si crea da solo, basta non toccarlo con le mani). E le funzioni di interazione, i fili, ecc. sono a vostra discrezione. - dipendono da voi. Questo è C++; non ci sono tali caratteristiche associate specificamente alla DLL.

Sì, posso scrivere la dll stessa, con un punto d'entrata vuoto))
Ma le informazioni sul punto di ingresso non è da nessuna parte, solo tinny, nessun google dà, nessuna letteratura simile ((.
Ho esattamente un problema con l'entry point, come scrivete le funzioni di interazione, inizializzazione, allocazione della memoria, thread, deinizializzazione, ecc.
So che tutto questo è implementato in un interruttore al punto di ingresso e questo è tutto, un deadlock)).
Non so nemmeno cosa cercare per studiare.

 
Roman:

Sì, posso scrivere la dll stessa, con un punto d'ingresso vuoto ))
Ma le informazioni sul punto di ingresso non sono da nessuna parte, solo l'inferno, né google né la letteratura simile ((
Ho esattamente un problema con l'entry point, come si scrive funzioni di interazione, inizializzazione, allocazione della memoria, thread, deinizializzazione, ecc.
So che tutto questo è implementato in un interruttore al punto di ingresso e questo è tutto, un deadlock)).
Non so nemmeno cosa cercare per studiare.

Credi che io sappia qualcosa sul punto d'ingresso? Non sono affari del re). C'è solo una funzione unica nella DLL che la definisce

// dllmain.cpp: определяет точку входа для приложения DLL.
#include "stdafx.h"

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                                         )
{
        switch (ul_reason_for_call)
        {
        case DLL_PROCESS_ATTACH:
        case DLL_THREAD_ATTACH:
        case DLL_THREAD_DETACH:
        case DLL_PROCESS_DETACH:
                break;
        }
        return TRUE;
}

Non c'è bisogno di capirlo). In futuro, nella maggior parte dei casi non c'è bisogno di usarlo quando si scrive e si utilizza la DLL. L'importante è non toccarlo con le mani).

 
Yuriy Asaulenko:

Credi che io sappia qualcosa sul punto d'ingresso? Non sono affari del re). C'è solo una funzione unica nella DLL che la definisce

Non c'è bisogno di capirlo). In futuro, nella maggior parte dei casi non c'è bisogno di usarlo quando si scrive e si utilizza la DLL. L'importante è non toccarlo con le mani).

No, devi capirlo, hai scritto la tua sequenza di azioni, quindi ho pensato che la conosci bene.
In questo punto di ingresso vengono eseguite tutte le azioni, l'inizializzazione delle funzioni, l'allocazione della memoria, la creazione di thread, la deinizializzazione, ecc.
Almeno cosa leggere su questo argomento?

Forum sul trading, sistemi di trading automatico e test di strategie di trading

Programmazione asincrona e multithread in MQL

Yuriy Asaulenko, 2019.07.27 21:25

Si crea un thread nella DLL e gli si passano i dati, si disconnette il thread e ci si dimentica di lui - terminerà da solo dopo aver finito il suo compito.
Quando si disconnette il thread nella DLL, il thread del terminale viene rilasciato. L'intero processo dura, credo, meno di un millisecondo.
A giudicare dal fatto che anche senza disconnettere il thread, il processo di scrittura nel database è di 4-5 ms. Beh, 60 ticks/s sono sufficienti per non essere triste per la chiamata asincrona dal terminale.


 
Roman:

No, devi capirlo, hai scritto tu stesso la sequenza, quindi ho pensato che la conoscessi bene.
Almeno cosa leggere sull'argomento?

Non c'è bisogno di capirlo, modificarlo, ecc. Se si crea un progetto DLL in VS, DllMain() viene creato da solo. Tutte le applicazioni Windows lo supportano automaticamente.

Il vostro compito è quello di scrivere funzioni di esportazione e, oltre ad esse, qualsiasi codice C++ di cui avete bisogno. La vostra DLL è pronta e funzionerà.

OOP è progettato principalmente per applicare gli oggetti senza avere alcuna idea sul loro funzionamento interno, in modo che ci si possa concentrare sulla soluzione esatta del proprio compito, piuttosto che imparare tutto e niente. Noi guidiamo un'auto, e possiamo non avere idea della sua elettronica e della costruzione del motore. È lo stesso nel caso della DLL.

E la funzione DllMain() che ho citato prima è presa da un progetto reale di una DLL piuttosto complessa, che svolge i suoi compiti.

 
Yuriy Asaulenko:

Non c'è bisogno di capirlo, modificarlo, ecc. Se si crea un progetto DLL in VS, DllMain() viene creato da solo. Tutte le applicazioni Windows lo supportano automaticamente.

Il vostro compito è quello di scrivere le funzioni di esportazione e, oltre ad esse, qualsiasi codice C++ di cui avete bisogno. La vostra DLL è pronta e funzionerà.

OOP è progettato principalmente per applicare oggetti senza avere alcuna idea del loro funzionamento interno. Guidiamo un'auto e forse non abbiamo idea della sua elettronica e della costruzione del motore. Nel caso della DLL, è lo stesso.

Questo è comprensibile, le funzioni stesse non sono un problema, con tutte le convenzioni come negli articoli 1 e 2 non c'è nessun problema.
Ma come presumo, per creare un thread per lafunzione chiamata,
nel caso DLL_THREAD_ATTACH, dobbiamo fare un po' di confusione con il C++
allocare la memoria, creare un thread per la funzione,
e poi pulire tutto in DLL_THREAD_DETACH, quindi non è così facile come sembra.

Perché dico così, perché ho provato una libreria asincrona, in cui i compiti vengono eseguiti in modo asincrono,
Volevo fare una dll da questa libreria, ma per qualche motivo si blocca sempre alla fine del programma, cioè cancellando Expert Advisor dal grafico.
Per questo motivo è necessario armeggiare con il punto di entrata e di uscita.

 
Roman:

Questo è il motivo per cui bisogna armeggiare con il punto di entrata e di uscita.

...cioè rimuovendo l'EA dal grafico, il mio terminale si blocca.

Non è necessario. Non è il punto di ingresso che è da biasimare. Stai facendo qualcosa di sbagliato.

Classi, fili, ecc. ecc. - tutto questo è perfettamente creato e funziona bene nella DLL senza alcuno sciamanesimo. Ma, al momento di uscire, tutti i TUOI processi nella DLL devono essere terminati e gli oggetti distrutti. Quando si esegue il debug della DLL questo accade). In C/C++ tutto il controllo è compito del programmatore, non del programma.

ZS Io faccio così. Chiamo una funzione DLL da un'applicazione, diciamo

bool job =true;

void Close() 
{
	 job = false;
	 delete Obj1;
	 delete Obj2;
	......
}
Con job=false tutti i processi vengono terminati, con delete vengono cancellati tutti gli oggetti per i quali è stata allocata memoria, ecc.
 
Yuriy Asaulenko:

Ma, nel momento in cui te ne vai, tutti i TUOI processi nella DLL devono essere completati.

Probabilmente è questo il problema, non lo sapevo, pensavo che la DLL completasse i propri processi quando si scollega.
Ci penserò su come terminare tutti i processi prima di uscire, grazie per il suggerimento.
Ma soloDLL_PROCESS_DETACH è responsabile di questo, e abbiamo bisogno di uccidere con forza tutti i processi in questo caso.

 
Roman:

Maquesto è esattamente ciò di cui è responsabile DLL_PROCESS_DETACH, e tutti i processi devono essere uccisi forzatamente in questo caso.

È responsabile della deconnessione della DLL con l'applicazione. DllMain() è responsabile del mantenimento del protocollo di comunicazione standard.DLL_PROCESS_DETACH riguarda altre cose). I vostri processi non ne sono interessati, sono solo affari vostri.

In MT c'è una funzione di spegnimento. Penso che sia OnClose(). Qui, da esso, tutti i processi e terminare chiamando la funzione appropriata DLL.

 
Yuriy Asaulenko:

È responsabile della disconnessione della DLL dall'applicazione. Non è interessato ai vostri processi, dipende interamente da voi.

OK, lo proverò. Grazie per aver trovato il tempo di spiegare i punti più sottili, grazie.

1...171819202122232425262728293031...40
Nuovo commento