C ++ 11 std :: hilos vs hilos posix


157

¿Por qué debería preferir uno u otro en la práctica? ¿Cuáles son las diferencias técnicas, excepto que std::threades una clase?


55
En la práctica deberías usarstd::async
Stephan Dollberg

@bamboon Esto sufre los mismos problemas que el std::threadque
padece

2
@hirschhornsalz desde la vista de soporte del compilador, sí. desde un punto de vista técnico, ofrece una seguridad excepcional, que std::threado pthreadsno.
Stephan Dollberg

15
Votado para reabrir. La solicitud de "diferencias técnicas" hace que esto sea objetivamente responsable. El alto recuento de votos indica que otros han encontrado esta publicación constructiva y útil.
Adrian McCarthy

Respuestas:


122

Si desea ejecutar código en muchas plataformas, busque hilos Posix. Están disponibles en casi todas partes y son bastante maduros. Por otro lado, si solo usa Linux / gcc std::threadestá perfectamente bien: tiene un nivel de abstracción más alto, una interfaz realmente buena y funciona muy bien con otras clases de C ++ 11.

std::threadDesafortunadamente, la clase C ++ 11 no funciona de manera confiable (todavía) en todas las plataformas, incluso si C ++ 11 parece estar disponible. Por ejemplo, en Android nativo std::threado Win64, simplemente no funciona o tiene graves cuellos de botella de rendimiento (a partir de 2012).

Un buen reemplazo es boost::thread: es muy similar a std::thread(en realidad es del mismo autor) y funciona de manera confiable, pero, por supuesto, introduce otra dependencia de una biblioteca de terceros.


Editar: a partir de 2017, std::threadfunciona principalmente en Android nativo. Algunas clases, como std::timed_mutextodavía no están implementadas.


19
¿Tiene alguna evidencia para respaldar estas afirmaciones de "cuello de botella de rendimiento"? Además, std::thready su estilo raii es bueno porque puede manejar excepciones de C ++ mientras que pthreads no puede salir de la caja.
Jesse Good

9
Ahora en 2014, ¿esta respuesta sigue siendo válida?
sentido

25
¿Qué pasa ahora, a principios de 2017?
rmobis

9
¿Qué pasa ahora, en 2017 Medio?
ligereza corre en órbita el

14
¿Qué pasa ahora, en 2018 Middle?
陳 力

59

La std::threadbiblioteca se implementa sobre pthreads en un entorno que admite pthreads (por ejemplo: libstdc ++).

Creo que la gran diferencia entre los dos es la abstracción. std::threades una biblioteca de clase C ++. La std::threadbiblioteca incluye muchas características abstractas, por ejemplo: bloqueos de ámbito, mutex recursivos, implementaciones de patrones de diseño futuro / prometedor y más.


44
+1de mi parte para señalar lo más importante, a saber, que std :: thread ofrece un mayor nivel de abstracción.
sbi

33

std::thread proporciona portabilidad en diferentes plataformas como Windows, MacOS y Linux.

Como mencionó @hirshhornsalz en los comentarios a continuación y la respuesta relacionada https://stackoverflow.com/a/13135425/1158895 , std::threadpuede que aún no esté completa en todas las plataformas. Aún así, (será en el futuro cercano) debería ser favorecido por sobre pthreadporque debería hacer que su aplicación esté más preparada para el futuro.


2
en realidad, std :: threads proporciona portabilidad en todas las plataformas que admiten C ++ 11, mientras que los hilos POSIX solo están disponibles en plataformas POSIX (o plataformas que se esfuerzan por lograr una compatibilidad mínima).
Tobias Langner

1
Desde el punto de vista práctico, esto es simplemente incorrecto. De hecho, hace unos meses decidí este razonamiento: fue un gran error. En la práctica, debes usar boost::threaden Win64 o Bionic (Android), porque std::threadtodavía carece de partes importantes, donde en Linux std::threadparece bastante maduro.
Gunther Piez

1
@hirschhornsalz, el punto de mi respuesta es señalar el beneficio de la portabilidad proporcionada por la implementación del hilo c ++ 11 en comparación con pthread. El OP no preguntó sobre el impulso, pero también es portátil.
Brady

3
@hirschhornsalz, en cuanto a su tono negativo y acusación de no usar hilos, simplemente no son constructivos y no merecen mucho esfuerzo de mi parte. Creo que al menos vale la pena mencionar que un comentario más constructivo habría sido señalar los problemas que tuvo al intentar usar std :: thread en diferentes plataformas.
Brady

3
Para resumir, c ++ 11 std :: thread solo se puede usar con versiones recientes de GCC. No está casi completo en Visual Studio, por lo tanto, no se puede usar en Windows. Y, por supuesto, está absolutamente ausente en los compiladores comerciales en UNIX (Sun Studio en Solaris, HP aCC en HP-UX, IBM vacpp en AIX). Por lo tanto, si su plataforma de destino es solo Linux, c ++ 11 std :: thread está bien; si también necesita Windows u otro UNIX, boost :: thread es el camino a seguir.
Vond

7

Para mí, la diferencia técnica decisiva es la ausencia de primitivas de manejo de señal en std en lugar de pthreads. La incapacidad de dictar adecuadamente el manejo de la señal en un proceso de Unix usando solo std es AFAIK una falla debilitante en el uso de std :: thread ya que impide configurar el patrón de manejo de señales de subprocesos múltiples de buena fe para procesar todas las señales en un dedicado enhebrar y bloquearlos en el resto. Usted está obligado a asumir que std :: thread se implementa usando pthreads y espera lo mejor cuando usa pthread_sigmask. El manejo adecuado de las señales no es negociable en la programación de sistemas Unix para la empresa.

A partir de 2016, std :: thread es un juguete; simple como eso.


77
Estoy en desacuerdo. Y el uso intensivo de señales es un patrón de diseño que se puede evitar para la mayoría de las aplicaciones.
Erik Alapää

Además, std::threadtrae seguridad de tipo que pthread no tiene.
alfC

-3

El OpenMP

http://www.openmp.org/

es un estándar multiproceso estandarizado basado en SMP que ha estado funcionando en Linux y Windows durante más de una década. OpenMP está disponible de forma predeterminada con todos los compiladores, incluidos GCC y Microsoft Visual Studio.

Una cosa a tener en cuenta, cuando se usa OpenMP, es que si hay más subprocesos que núcleos de CPU, entonces el rendimiento disminuirá debido a la sobrecarga relacionada con el cambio de contexto. La segunda cosa a tener en cuenta es que la inicialización de un subproceso real a nivel de sistema operativo es relativamente costoso. La inicialización es una fracción de segundo, pero en algunas aplicaciones las fracciones muy pequeñas se acumulan a un costo considerable.

Para la concurrencia relacionada con los requisitos de la arquitectura de software Es posible que desee buscar alguna implementación de "hilos ligeros" o "hilos verdes" en lugar de utilizar OpenMP. La diferencia es que los hilos de OpenMP son reales, a nivel del sistema operativo, hilos, pero los "hilos verdes" pueden ser simplemente "hilos simulados" que se ejecutan utilizando un pequeño número de hilos reales.


66
Sin faltar el respeto, pero ¿cómo se relaciona esto con la pregunta principal?
SRG
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.