Programmazione asincrona e multithread in MQL - pagina 33

[Yuriy Asaulenko]

Roman:

Mi piace tutto )) diversi approcci per capire e poi scegliere quello che ha più senso per me e si adatta alle esigenze, è semplice.

Tutto il mondo lavora con DLL, con le meraviglie di ICL solo un gruppo di settari che pensano che sia la massima competenza.

[Roman]

Yuriy Asaulenko:
Tutto il mondo lavora con DLL, con i miracoli di ICL solo un gruppo di settari che pensano che sia la massima competenza.

È esilarante, e non potrei essere più d'accordo ))))
Ben fatto per leggere i manuali e pensare alle opzioni offerte.
Grazie a tutti coloro che davvero non flub, suggerito varie soluzioni.
Ora c'è molto da scegliere.

[Yuriy Asaulenko]

A proposito, mi ricorda una vecchia barzelletta.

Congresso Medico Internazionale. Relazione della delegazione russa - "Rimozione delle tonsille attraverso l'ano".

L'abbiamo letto. Seguono le domande del pubblico.

- Ammiriamo l'abilità e i risultati della chirurgia russa. Ma perché attraverso il passaggio posteriore?

- È così che facciamo tutti.

[Roman]

Vict:

Ho capito bene che Futures e Async sono standard solo per C++?
Non c'è una libreria simile in C?

[[Eliminato]]

Roman:

Ho capito bene che Futures e Async sono standard solo per C++?
Non c'è una libreria simile in C?

Giusto. Cish std ha anche il supporto multi-threading https://en.cppreference.com/w/c/thread

ZS: potresti anche leggere il libro "c++ concurrency in action" di anthony williams. Per esempio, nel capitolo 9 scrive thread pool.

[Roman]

Vict:

Giusto. Cish std ha anche il supporto multi-threading https://en.cppreference.com/w/c/thread

HH: potresti anche leggere il libro "c++ concurrency in action" di anthony williams. Per esempio, nel capitolo 9 scrive thread pool.

Non ho notato il link Vedi anche in fondo alla pagina ))
Capito,std::thread è in C, mastd:::async non lo è ((
Sto leggendo ora questo libro )) Parallel C++ programming in action, Anthony Williams.
Il libro è in allegato, async inizia al capitolo 4, abbastanza facile da leggere.
E Kurt Ganteroth, nel suo libro Optimizing C++ Programs, sostiene che è 14 volte più costoso creare threads che usare std::async.
Questo è il motivo per cui inizialmente volevo usare async, ma non sapevo molto sui thread in C/C++,
quindi sei thread sono più costosi, cadono comunque per l'uso.
Ma si scopre che in C,std::async non esiste((

[[Eliminato]]

Roman:

Non ho notato il link Vedi anche in fondo alla pagina ))
Capito,std::thread è in C, ma std::: async non lo è ((
Sto leggendo ora questo libro )) Programmazione parallela C++ in azione, di Anthony Williams.
Se siete interessati il libro è in allegato, async inizia al capitolo 4, abbastanza facile da leggere.
E Kurt Ganteroth, nel suo libro Optimizing C++ Programs, afferma che è 14 volte più costoso creare threads che usare std::async.
Questo è il motivo per cui inizialmente volevo usare async, ma non sapevo molto sui thread in C/C++,
quindi sei fili sono più costosi, non vale la pena usarli comunque.
Ma si scopre che in C,std:: async non esiste ((

Un filo non è più costoso, è solo uno strumento di livello inferiore con cui si può fare qualsiasi cosa. Potete fare il vostro semplice pool di thread su "thread costosi" - un'ora di scrittura (o prendere una lib già pronta).

creare thread è 14 volte più costoso che usare std::async.

Forse se c'è un pool di thread dentro l'async, ma non è sempre il caso https://stackoverflow.com/questions/15666443/which-stdasync-implementations-use-thread-pools.

Di conseguenza, async è una scatola nera e incontrollabile. Non vi esorto a scrivere il vostro pool, se vi sentite a vostro agio con l'async, bene.

ZS: c'erano voci che l'async sarebbe stato rimosso da c++17.

[Andrei Novichkov]

Async può essere eseguito in modo sincrono, c'è un flag per questo. Penso che il thread pooling su plus sia complicato e ha senso scriverlo solo in caso di estrema necessità. Fareste meglio a dare un'occhiata a Sharp, a quel thread pooling.

Consiglierei anche "Scott Meyers: Efficient and Modern C++". 2016, facile da leggere, come un blockbuster. Ho allegato l'archivio qui sotto. Ha un capitolo interessante sui fili. E in generale, Meyers dovrebbe essere letto, perché si deve )))

[[Eliminato]]

Andrei Novichkov:

Penso che il thread pooling sui professionisti sia difficile e ha senso solo se è assolutamente necessario.

Non rendere le cose più difficili del necessario. Se non volete scriverlo voi stessi, potete facilmente prenderne uno già pronto, una rapida ricerca qui https://github.com/vit-vit/ctpl. Ed è qualcosa di meno prevedibile, a differenza di async (che è spesso criticato).

[Andrei Novichkov]

Vict:

Non rendere le cose più difficili del necessario. Se non volete scriverlo da soli, potete facilmente ottenerne uno già pronto, ecco una rapida ricerca https://github.com/vit-vit/ctpl. Ed è qualcosa di meno prevedibile, a differenza di async (che è spesso criticato).

No, non ne ho voglia )))))) Ma una ricerca sommaria è anche, umm, irta. Mi sono imbattuto in un sacco di spazzatura su Github. Ma sono interessato a un altro, ci sono dei compiti che richiederebbero davvero il thread pooling? Non solo creare un thread, dimenticarlo e aspettare che finisca, ma metterlo in comune come descrive Williams? Sembra essere un esempio di bancomat lì, se non mi sbaglio - quale compito potrebbe giustificare un tale miracolo di judo? Non riesco ancora a pensare a un tale compito. E perché non guardi ThreadPool dove tutto è già fatto, c'è documentazione ed esempi.