C ++ 11 std :: threads vs posix threads


157

Por que devo preferir um ou outro na prática? Quais são as diferenças técnicas, exceto que std::threadé uma classe?


5
Na prática, você deve usarstd::async
Stephan Dollberg 30/10/12

@bamboon Isso sofre dos mesmos problemas que std::threado #
Gunther Piez 30/10/12

2
@hirschhornsalz do modo de exibição de suporte ao compilador, sim. do ponto de vista técnico, oferece segurança excepcional, que pode std::threadou pthreadsnão.
30512 Stephanieberg

15
Votou para reabrir. O pedido de "diferenças técnicas" torna isso objetivamente responsável. A alta contagem de votos indica que outros acharam esta publicação construtiva e útil.
Adrian McCarthy

Respostas:


122

Se você deseja executar o código em muitas plataformas, vá para Posix Threads. Eles estão disponíveis em quase todos os lugares e são bastante maduros. Por outro lado, se você só usa Linux / gcc, std::threadestá perfeitamente bem - ele possui um nível de abstração mais alto, uma interface muito boa e funciona bem com outras classes C ++ 11.

std::threadInfelizmente, a classe C ++ 11 ainda não funciona de maneira confiável em todas as plataformas, mesmo que o C ++ 11 pareça disponível. Por exemplo, no Android nativo std::threadou no Win64, ele simplesmente não funciona ou possui fortes gargalos de desempenho (a partir de 2012).

Um bom substituto é boost::thread- é muito semelhante a std::thread(na verdade, é do mesmo autor) e funciona de maneira confiável, mas, é claro, introduz outra dependência de uma biblioteca de terceiros.


Edit: A partir de 2017, std::threadfunciona principalmente no Android nativo. Algumas classes, como std::timed_mutexainda não estão implementadas.


19
Você tem alguma evidência para fazer backup dessas alegações de "gargalo de desempenho"? Além disso, std::threadseu estilo raii é bom porque ele pode lidar com exceções de C ++, enquanto os pthreads não podem sair da caixa.
Jesse Boa

9
Agora em 2014, essa resposta ainda é válida?
Nonsensation

25
E agora, a partir de 2017?
Rmobis

9
E agora, no 2017 Middle?
Lightness Races in Orbit

14
E agora, no 2018 Middle?
陳力

59

A std::threadbiblioteca é implementada sobre pthreads em um ambiente que suporta pthreads (por exemplo: libstdc ++).

Eu acho que a grande diferença entre os dois é abstração. std::threadé uma biblioteca de classes C ++. A std::threadbiblioteca inclui muitos recursos abstratos, por exemplo: bloqueios com escopo definido, mutexes recursivos, implementações de padrões de design de futuro / promessa e muito mais.


4
+1de mim por apontar a coisa mais importante, a saber, que std :: thread oferece um nível mais alto de abstração.
Sb

33

std::thread fornece portabilidade em diferentes plataformas, como Windows, MacOS e Linux.

Conforme mencionado por @hirshhornsalz nos comentários abaixo e na resposta relacionada https://stackoverflow.com/a/13135425/1158895 , std::threadtalvez ainda não esteja completo em todas as plataformas. Mesmo assim, (será em um futuro próximo), deve ser favorecido pthread, porque deve tornar seu aplicativo mais à prova de futuro.


2
na verdade, std :: threads fornece portabilidade em todas as plataformas que suportam C ++ 11, enquanto os threads POSIX estão disponíveis apenas em plataformas POSIX (ou plataformas que buscam alguma compatibilidade mínima).
Tobias Langner 30/10/12

1
Do ponto de vista prático, isso está errado. Na verdade, eu decidi há alguns meses sobre esse raciocínio - foi um grande erro. Na prática, você precisa usar o boost::threadWin64 ou o Bionic (Android), porque std::threadainda falta grandes partes, enquanto no Linux std::threadparece bastante maduro.
Gunther Piez

1
@hirschhornsalz, o objetivo da minha resposta é apontar o benefício da portabilidade fornecida pela implementação do encadeamento c ++ 11 em comparação com o pthread. O OP não perguntou sobre impulso, mas também é portátil.
Brady

3
@hirschhornsalz, quanto ao seu tom negativo e acusação de nunca usar tópicos, eles são simplesmente não-intrusivos e não merecem muito esforço da minha parte. Eu acho que vale a pena mencionar que um comentário mais construtivo teria sido apontar os problemas que você estava tentando usar std :: thread em diferentes plataformas.
Brady

3
Para resumir, o c ++ 11 std :: thread é utilizável apenas nas versões recentes do GCC. Não está quase completo no Visual Studio, portanto, não pode ser usado no Windows. E, é claro, isso está absolutamente ausente nos compiladores comerciais no UNIX (Sun Studio no Solaris, HP aCC no HP-UX, IBM vacpp no ​​AIX). Portanto, se sua plataforma de destino for apenas Linux - c ++ 11 std :: thread está correto; se você também precisa do Windows ou outro UNIX - boost :: thread é o caminho a percorrer.
vond 30/10/12

7

Para mim, a diferença técnica decisiva é a ausência de primitivas de manipulação de sinal em std, em oposição a pthreads. A incapacidade de ditar adequadamente a manipulação de sinais em um processo Unix usando std sozinho é AFAIK uma falha debilitante no uso de std :: thread, pois impede a configuração do padrão de manipulação de sinais multithread de boa-fé para processar todos os sinais em um dedicado rosqueie e bloqueie-os no restante. Você é forçado a assumir que std :: thread é implementado usando pthreads e espera o melhor ao usar pthread_sigmask. O tratamento adequado de sinais não é negociável na programação de sistemas Unix para a empresa.

Como em 2016, std :: thread é um brinquedo; Simples assim.


7
Discordo. E o uso intenso de sinais é um padrão de design que pode ser evitado na maioria das aplicações.
Erik Alapää

Além disso, std::threadtraz segurança de tipo que o pthread não possui.
Alf20 #

-3

O OpenMP

http://www.openmp.org/

é um padrão multithreading padronizado e baseado em SMP que já trabalha no Linux e Windows há mais de uma década. O OpenMP está disponível por padrão com todos os compiladores, incluindo o GCC e o Microsoft Visual Studio.

Uma coisa a observar, ao usar o OpenMP, é que, se houver mais threads do que núcleos de CPU, o desempenho diminuirá devido à sobrecarga relacionada à alternância de contexto. A segunda coisa a ter em mente é que a inicialização de um thread real no nível do sistema operacional é relativamente cara. A inicialização é uma fração de segundo, mas em algumas aplicações as frações muito pequenas se acumulam para uma despesa considerável.

Para simultaneidade relacionada aos requisitos de arquitetura de software, convém procurar alguma implementação de "threads leves" ou "threads verdes" em vez de usar o OpenMP. A diferença é que os threads do OpenMP são reais, no nível do sistema operacional, threads, mas os "threads verdes" podem ser apenas "threads simulados" que são executados usando um pequeno número de threads reais.


6
Sem desrespeito, mas como isso está relacionado à questão principal?
SRG
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.