C ++ 11 std :: threads vs posix threads

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

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.

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.

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.

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.

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.