C ++ 11 std :: thread vs posix thread


157

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


5
In pratica dovresti usarestd::async
Stephan Dollberg il

@bamboon Questo soffre degli stessi problemi che std::threadha
Gunther Piez,

2
@hirschhornsalz dal punto di vista del compilatore, sì. da un punto di vista tecnico offre una sicurezza eccezionale, che std::threado pthreadsno.
Stephan Dollberg,

15
Votato per riaprire. La richiesta di "differenze tecniche" rende questo obiettivamente rispondente. L'alto numero di voti indica che altri hanno trovato questo post costruttivo e utile.
Adrian McCarthy,

Risposte:


122

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.


19
Hai qualche prova a sostegno di queste affermazioni sul "collo di bottiglia delle prestazioni"? Inoltre, std::threade il suo stile raii è buono perché può gestire le eccezioni C ++ mentre pthreads non può essere pronto.
Jesse Good,

9
Ora, nel 2014, questa risposta è ancora valida?
assenso

25
E adesso, all'inizio del 2017?
rmobis,

9
Che dire ora, nel 2017 Middle?
Razze di leggerezza in orbita,

14
Che dire ora, nel Medio 2018?
陳 力

59

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.


4
+1da parte mia per aver sottolineato la cosa più importante, vale a dire che std :: thread offre un livello più alto di astrazione.
sbi,

33

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.


2
in realtà, std :: thread offre la portabilità su tutte le piattaforme che supportano C ++ 11, mentre i thread POSIX sono disponibili solo su piattaforme POSIX (o piattaforme che cercano una compatibilità minima).
Tobias Langner,

1
Dal punto di vista pratico questo è semplicemente sbagliato. In realtà ho deciso qualche mese fa su questo ragionamento: è stato un grave errore. In pratica devi usare boost::threadsu Win64 o Bionic (Android), perché std::threadmancano ancora grandi parti, dove su Linux std::threadsembra abbastanza maturo.
Gunther Piez,

1
@hirschhornsalz, il punto della mia risposta è di sottolineare il vantaggio della portabilità fornita dall'implementazione del thread c ++ 11 rispetto a pthread. L'OP non ha chiesto il potenziamento, ma è anche portatile.
Brady,

3
@hirschhornsalz, per quanto riguarda il tuo tono negativo e l'accusa di non aver mai usato i thread, sono semplicemente poco intuitivi e non meritano molto sforzo da parte mia. Penso che valga la pena menzionare almeno un commento più costruttivo per sottolineare i problemi che hai provato a utilizzare std :: thread su piattaforme diverse.
Brady,

3
Per riassumere, c ++ 11 std :: thread è utilizzabile solo con le versioni recenti di GCC. Non è quasi completo in Visual Studio, quindi non utilizzabile su Windows. E ovviamente manca assolutamente nei compilatori commerciali su UNIX (Sun Studio su Solaris, HP aCC su HP-UX, IBM vacpp su AIX). Pertanto, se la tua piattaforma di destinazione è solo Linux - c ++ 11 std :: thread va bene; se hai bisogno anche di Windows o di altri UNIX - boost :: thread è la strada da percorrere.
Vond

7

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.


7
Non sono d'accordo. E l'uso pesante dei segnali è un modello di progettazione che può essere evitato per la maggior parte delle applicazioni.
Erik Alapää,

Inoltre, std::threadporta la sicurezza del tipo che pthread non ha.
alfC

-3

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.


6
Nessuna mancanza di rispetto, ma come si collega alla domanda principale?
SRG
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.