2010-03-08 21 views
9

estoy experimentando con múltiples hilos en Windows y me preguntaba si deboPthreads en Visual C++

Pthreads aprendizaje sería útil si trataba de desarrollar tales aplicaciones en diferentes plataformas, pero ¿estoy perdiendo algo al no aprender Win32 API? ¿O ambos son lo suficientemente similares para que aprender uno me permita descubrir el otro fácilmente?

+3

Puede usar Boost.Thread si eso es posible. Funciona igual para todas las plataformas (admite todas las plataformas principales). –

+0

Si está experimentando, la biblioteca POSIX Threads for Windows puede ser muy útil por las razones que menciona. Si desea lanzar un producto, entonces debe considerar si la licencia LGPL es compatible con la forma en que desea lanzar su producto. –

Respuesta

7
  1. Usar Boost Threads. Cuando C++ 0x aparezca, tendremos std :: hilos. Boost threads tiene la implementación más cercana a std threads.

  2. else utiliza pthreads. Pthreads es el segundo más cercano a std :: threads, y formó la base principal de std threads y boost threads.

  3. else hacer ventanas enhebrado directamente. Todavía puede aprender cómo funcionan los hilos y formar un modelo mental de las cosas. Simplemente tiende a usar primitivas de sincronización que son un poco no estándar.

0

He encontrado que la pervivencia de pthreads salva mi cordura por tres motivos:

  • no tengo que luchar a través docs WinAPI, que no son habitualmente de cualquier calidad.
  • Cualquiera que haga mucho con los hilos puede ayudar con pthreads. He encontrado infinitamente más buenas fuentes de información sobre pthreads en línea.
  • Siempre que pongo en práctica algo más complicado que "Hello World" con la API de Windows, me parece que se necesita mucho más tiempo que uno podría razonablemente esperar . Sin embargo, esa es solo mi entrada empírica .

En lo que respecta a las capacidades, nunca he encontrado pthreads que falten en nada, así que no creo haber encontrado la necesidad de buscar en otro lado. También se puede decir mucho sobre el aprendizaje de una biblioteca que podrá utilizar en cualquier entorno que aborde.

+0

Downvoted para UNIX FUD. –

+0

No puedo decir exactamente que soy un adherente de Unix, pero tampoco me gustan las interfaces demasiado diseñadas. Win32 hilos son una pega que he luchado en la última semana. Otro fue CreateProcess. Estas son interfaces para tareas simples que han sido sobrearquitecturadas hasta el punto de que no tienen un funcionamiento predeterminado simple. Los documentos para CreateProcess apuntan al modelo de seguridad como el motivo del exceso de configuración. He trabajado con el modelo Solaris de lo mismo y utilizan: sorpresa, sorpresa, fork/exec con un conjunto OPCIONAL de herramientas para administrar la política de seguridad. FUD. Derecha. – Sniggerfardimungus

+0

Nuevo y abrumador no es lo mismo que malo. – ROAR

1

Si usted va a hacer mucho de programación de Windows, que pagará a aprender el construcciones básicas de enhebrado Win32: secciones críticas, funciones entrelazadas, CreateThread, WaitFor*Object, etc. No son difíciles de entender, y se traducen de forma transparente a equivalen t objetos en otros marcos de enhebrado.

Sin embargo, para construcciones de subprocesamiento más avanzadas como semáforos, eventos, etc., utilizaría la biblioteca pthreads, ya que la documentación sobre estos tiende a ser más clara y los ejemplos más abundantes.

1

Si está utilizando C/C++, intente utilizar las funciones de subproceso del tiempo de ejecución de C/C++. Si usa el Win32 (u otras funciones que no sean CRT para crear subprocesos) el CRT podría no inicializarse correctamente en el nuevo subproceso, causando todo tipo de problema (puede leerlo aquí: http://www.codeguru.com/forum/archive/index.php/t-371305.html).

Sin embargo, la mayoría de las funciones de subprocesos (en CRT, Win32 o pthread) se basan en la funcionalidad para crear subprocesos, sincronizar subprocesos y destruir subprocesos. En la práctica, esto no siempre es tan fácil de usar.

En el último año, hay una tendencia para ir al enhebrado basado en tareas (bueno, lo llamo así, no sé cuál es el nombre oficial). En lugar de iniciar un hilo y luego ejecutar alguna lógica en él, en el enhebrado basado en tareas crea una tarea y luego le pide a la 'lógica de enhebrado' que ejecute la tarea.

Los sistemas compatibles con esta nueva forma de trabajar con hilos son:

  • Visual Studio 2010 (que tendremos que esperar unos días para ello)
  • Intel roscado Building Blocks

Visual Studio 2010 incluso tiene (parece) una lógica de depuración especial para depurar las 'tareas paralelas'.