¿La programación basada en tareas en C ++ requeriría nuevas características estándar de lenguaje?

Así que vi este video en Youtube con todos estos maestros de C ++ en GoingNative 2012: panel interactivo donde todos podían hacer las preguntas.

Este es el video del que hablaba: GoingNative 2012 - Día 1 - Panel interactivo: La importancia de ser nativo

Y a la hora 0:24:00 alguien hizo una pregunta muy interesante:

Hemos estado haciendo programación concurrente durante algún tiempo usando pthreads, usando hilos de Windows, y así sucesivamente, y estoy muy feliz de que C ++ y C se hayan puesto al día con la programación concurrente, pero me parece que ya lleva cinco años o diez años porque en este momento tenemos todos estos multinúcleos potentes y la programación de estos multinúcleos realmente no debería basarse en subprocesos, sino en tareas [...] y Microsoft tiene la biblioteca PPL y así sucesivamente, y esto es totalmente no se refleja en el estándar C ++. [...] Lo único que me temo es que el estándar podría estar bloqueado en subprocesos y hacer que sea muy difícil pasar a la Programación basada en tareas ...

Ahora soy bastante nuevo en estos conceptos y estoy un poco confundido. Lo que en realidad es programación basada en tareas . ¿Este término se refiere a lo mismo que se refiere a la Programación sin bloqueo ? ¿Son estos dos términos equivalentes o hay algún vínculo entre ellos?

— mosquito
fuente

No he tenido la oportunidad de trabajar con el último estándar de C ++, por lo que esto podría estar muy lejos, pero es coherente con las preocupaciones en su presupuesto. En mi vocabulario, una tarea es equivalente a un proceso. Un proceso / tarea tiene su propia memoria asignada. Diferentes procesos no pueden acceder a la memoria / datos de otro proceso (al menos sin saltar a través de los aros). Un hilo puede acceder a la memoria / datos de otros hilos que se ejecutan en el mismo proceso. Por lo tanto, en un sistema multinúcleo, los procesos se pueden ejecutar en CPU separadas sin problemas, pero los hilos tendrían que coordinarse entre sí al acceder a datos / memoria compartidos.

— Dunk

... creando así la necesidad de saltar a través de los aros en un sistema multinúcleo si los subprocesos se ejecutan en diferentes CPU. Esto es bastante difícil de hacer con un programador en el bucle, es dudoso que el hardware / compilador pueda manejar el caso genérico de manera confiable y eficiente.

— Dunk

Gracias a todos por todas estas buenas respuestas, pero todavía hay una pregunta sin respuesta:

Does this term refer to the same thing that Lock-Free Programming refers to? Are these two equivalent terms or are there any links between them?

¿Alguien puede explicar? ¿Todas estas bibliotecas basadas en tareas están construidas también sobre hilos o hay alguna otra forma en que se implementaron? ¡Gracias!

Respuestas:

Microsoft tiene la "Biblioteca paralela de tareas" o TPL.

Es una abstracción de nivel superior sobre subprocesos y está basada en la biblioteca, por lo que no veo ninguna razón por la que no se pueda construir algo similar en C ++, ya que el TPL ya está basado en subprocesos y no depende de características especiales en el estándar de lenguaje para su implementación (aunque las palabras clave asyncy awaitse agregaron al compilador de C # para facilitar dicha programación).

Una tarea en la ecosistema de Microsoft es más o menos equivalente a un futuro o una promesa . Básicamente, es una función sin bloqueo (asíncrona); lo llama, le devuelve el control mientras se ejecuta en un nuevo hilo, y luego recupera el valor de retorno en algún momento posterior cuando esté disponible.

El TPL tiene otras funciones como Parallel.For, que le permite procesar un bucle al mismo tiempo, utilizando múltiples hilos. Todas estas cosas podrían implementarse en C ++ como funciones de biblioteca. De hecho, dicha biblioteca ya ha sido escrita .

Hasta donde yo sé, la PPL (Biblioteca de patrones paralelos para Microsoft C ++) no depende de ninguna característica especial del lenguaje.

— Robert Harvey
fuente

Una distinción importante entre ay Taska Threades que una tarea no representa necesariamente una función que se ejecuta en otro hilo. Representa cualquier cosa que pueda terminar o generar un valor, mientras no se ejecuta en el hilo actual. Puede ser el resultado de que no se ejecute ningún subproceso si no representa el trabajo vinculado a la CPU. Probablemente el ejemplo más común es IO asíncrono. No representa cuándo una función termina en otro hilo; representa cuando se activa un gancho de sistema operativo particular. Taskno le importa cómo se completa y lo trata como "cualquier operación asincrónica".

— Servicio

Realmente no puedo mostrar un buen ejemplo en un comentario ... grr.

— Veré

@Servy: Derecha; La finalización de una operación asincrónica podría ser el resultado de una devolución de llamada de método en respuesta a algún evento externo.

— Robert Harvey

Sí, ese es un ejemplo. En general, es fácil configurar algo usando a TaskCompletionSource. La idea es que cree una tarea y luego continúe ejecutándose, y ese hilo eventualmente hace algo que termina configurando el resultado del TCS, completando así la tarea sin requerir más de un hilo para ejecutar.

— Servicio

Ha habido bibliotecas de subprocesos a través de bloques durante siglos en cpp. Hay bloques de creación de subprocesos de Intel que son bastante buenos, y luego hay cosas similares como OpenMP que le permite abstraer el subproceso de una manera 'deje que el sistema lo haga por usted' (esto es compatible con VC ++, debe configurar el / bandera de openmp en tus compilaciones)

Microsoft también está trabajando en Casablanca , que podría no ser una biblioteca de tareas verdaderamente genérica, pero es un marco para escribir sistemas basados en tareas (principalmente para fines de aplicaciones web) que usan algo similar al modelo de actor de Erlang

— gbjbaanb
fuente