C ++ 11 std :: thread vs posix thread

Perché dovrei preferire l'uno o l'altro in pratica? Quali sono le differenze tecniche tranne che std::threadè una classe?

Se vuoi eseguire il codice su molte piattaforme, scegli Posix Threads. Sono disponibili quasi ovunque e sono abbastanza maturi. D'altra parte, se usi solo Linux / gcc std::threadva benissimo: ha un livello di astrazione più alto, un'interfaccia davvero buona e gioca bene con altre classi C ++ 11.

La std::threadclasse C ++ 11 purtroppo non funziona in modo affidabile (ancora) su ogni piattaforma, anche se C ++ 11 sembra disponibile. Ad esempio in Android nativo std::threado Win64 non funziona o presenta gravi colli di bottiglia nelle prestazioni (a partire dal 2012).

Un buon sostituto è boost::thread- è molto simile a std::thread(in realtà è dello stesso autore) e funziona in modo affidabile, ma, naturalmente, introduce un'altra dipendenza da una libreria di terze parti.

Modifica: a partire dal 2017, std::threadfunziona principalmente su Android nativo. Alcune classi, ad esempio, std::timed_mutexnon sono ancora implementate.

La std::threadlibreria è implementata su pthreads in un ambiente che supporta pthreads (ad esempio: libstdc ++).

Penso che la grande differenza tra i due sia l'astrazione. std::threadè una libreria di classi C ++. La std::threadlibreria include molte funzioni astratte, ad esempio: blocchi con ambito, mutex ricorsivi, implementazioni di modelli di progettazione futura / promessa e altro ancora.

std::thread fornisce portabilità su piattaforme diverse come Windows, MacOS e Linux.

Come menzionato da @hirshhornsalz nei commenti seguenti e relativa risposta https://stackoverflow.com/a/13135425/1158895 , std::threadpotrebbe non essere ancora completo su tutte le piattaforme. Anche, (lo sarà nel prossimo futuro) dovrebbe essere preferito rispetto a quello pthreadperché dovrebbe rendere la tua applicazione più a prova di futuro.

Per me la differenza tecnica decisiva è l'assenza di primitive di gestione del segnale in std rispetto a pthreads. L'incapacità di dettare correttamente la gestione del segnale in un processo Unix usando solo std è AFAIK un difetto debilitante nell'uso di std :: thread in quanto impedisce di impostare il modello di gestione del segnale multi-thread in buona fede per elaborare tutti i segnali in un apposito infilarli e bloccarli nel resto. Sei costretto ad assumere che std :: thread sia implementato usando pthreads e speri il meglio quando usi pthread_sigmask. La gestione corretta dei segnali non è negoziabile nella programmazione dei sistemi Unix per l'impresa.

A partire dal 2016, std :: thread è un giocattolo; semplice come quella.

OpenMP

http://www.openmp.org/

è uno standard multithreading standardizzato basato su SMP che lavora su Linux e Windows già da oltre un decennio. OpenMP è disponibile per impostazione predefinita con tutti i compilatori, inclusi GCC e Microsoft Visual Studio.

Una cosa a cui prestare attenzione, quando si utilizza OpenMP, è che se ci sono più thread di quanti sono i core della CPU, le prestazioni diminuiranno a causa del sovraccarico relativo al cambio di contesto. La seconda cosa da tenere a mente è che l'inizializzazione di un thread effettivo a livello di sistema operativo è relativamente costosa. L'inizializzazione è una frazione di secondo, ma in alcune applicazioni le frazioni molto piccole si accumulano con una spesa considerevole.

Per la concorrenza relativa ai requisiti di architettura software È possibile che si desideri cercare alcune implementazioni di "thread leggeri" o "thread verdi" anziché utilizzare OpenMP. La differenza è che i thread OpenMP sono effettivi, a livello di sistema operativo, thread, ma i "thread verdi" possono essere solo "thread simulati" che vengono eseguiti utilizzando un numero limitato di thread reali.