La programación concurrente se refiere a las operaciones que parecen superponerse y se refiere principalmente a la complejidad que surge debido al flujo de control no determinista. Los costos cuantitativos asociados con los programas concurrentes suelen ser tanto el rendimiento como la latencia. Los programas concurrentes a menudo están vinculados a IO, pero no siempre, por ejemplo, los colectores de basura concurrentes están completamente en la CPU. El ejemplo pedagógico de un programa concurrente es un rastreador web. Este programa inicia las solicitudes de páginas web y acepta las respuestas simultáneamente a medida que los resultados de las descargas estén disponibles, acumulando un conjunto de páginas que ya han sido visitadas. El flujo de control no es determinista porque las respuestas no se reciben necesariamente en el mismo orden cada vez que se ejecuta el programa. Esta característica puede hacer que sea muy difícil depurar programas concurrentes. Algunas aplicaciones son fundamentalmente concurrentes, por ejemplo, los servidores web deben manejar las conexiones del cliente simultáneamente. Erlang es quizás el más prometedor próximo lenguaje para programación altamente concurrente.

La programación paralela se refiere a operaciones que se superponen para el objetivo específico de mejorar el rendimiento. Las dificultades de la programación concurrente se evaden haciendo determinista el flujo de control. Por lo general, los programas generan conjuntos de tareas secundarias que se ejecutan en paralelo y la tarea principal solo continúa una vez que cada subtarea ha terminado. Esto hace que los programas paralelos sean mucho más fáciles de depurar. La parte difícil de la programación paralela es optimización del rendimiento con respecto a cuestiones como la granularidad y la comunicación. Esto último sigue siendo un problema en el contexto de los multicores porque hay un costo considerable asociado con la transferencia de datos de un caché a otro. Matriz densa-matriz multiplicada es un ejemplo pedagógico de programación paralela y se puede resolver de manera eficiente utilizando el algoritmo divide y vencerás de Straasen y atacando los subproblemas en paralelo. Cilk es quizás el lenguaje más prometedor para programación paralela de alto rendimiento en ordenadores de memoria compartida (incluidos multicores).

Https://joearms.github.io/published/2013-04-05-concurrent-and-parallel-programming.html

Concurrente = Dos colas y una máquina de café.

Paralelo = Dos colas y dos máquinas de café.

Interpretando la pregunta original como paralelo/concurrente computaciónen lugar de programación.

En computación concurrente dos cálculos avanzan independientemente uno del otro. El segundo cálculo no tiene que esperar hasta que el primero esté terminado para que avance. Sin embargo, no indica el mecanismo de cómo se logra esto. En la configuración de un solo núcleo, se requiere suspender y alternar entre hilos (también llamado preventivo multithreading).

En cálculo paralelo dos cálculos avanzan simultáneamente - eso es literalmente al mismo tiempo. Esto no es posible con una sola CPU y requiere una configuración de varios núcleos en su lugar.

Versus

De acuerdo con: "Paralelo vs Concurrente en Nodo.js " .

Creo que la programación concurrente se refiere a la programación multiproceso que se trata de permitir que su programa ejecute múltiples subprocesos, absteniéndose de los detalles del hardware.

La programación en paralelo se refiere al diseño específico de los algoritmos del programa para aprovechar la ejecución en paralelo disponible. Por ejemplo, puede ejecutar en paralelo dos ramas de algunos algoritmos con la expectativa de que llegará al resultado antes (en promedio) de lo que lo haría si primero comprobó el primero, entonces el segunda rama.

En la vista de un procesador, puede ser descrito por este pic

En la vista de un procesador, puede ser descrito por este pic

Encontré este contenido en algún blog. Creo que es útil y relevante.

Concurrencia y paralelismo NO son lo mismo. Dos tareas T1 y T2 son concurrentes si el orden en el que las dos tareas se ejecutan en el tiempo no está predeterminado,

T1 puede ser ejecutado y terminado antes de T2, T2 puede ser ejecutado y terminado antes de T1, T1 y T2 pueden ejecutarse simultáneamente en la misma instancia de tiempo (paralelismo), T1 y T2 pueden ejecutarse alternativamente, ... Si dos los subprocesos concurrentes están programados por el sistema operativo para ejecutarse en un procesador de un solo núcleo que no sea SMT que no sea CMP, puede obtener concurrencia pero no paralelismo. El paralelismo es posible en sistemas multinúcleo, multiprocesador o distribuidos.

La concurrencia se refiere a menudo como una propiedad de un programa, y es un concepto más general que el paralelismo.

Fuente: https://blogs.oracle.com/yuanlin/entry/concurrency_vs_parallelism_concurrent_programming

En la programación, la concurrencia es la composición de forma independiente ejecución de procesos, mientras que el paralelismo es la ejecución simultánea de cálculos (posiblemente relacionados).
- Andrew Gerrand -

Y

La concurrencia es la composición de la ejecución independiente calculo. La concurrencia es una forma de estructurar el software, particularmente como una forma de escribir código limpio que interactúa bien con el mundo real. No es paralelismo.

La concurrencia no es paralelismo, aunque habilita el paralelismo. Si solo tiene un procesador, su programa todavía puede ser concurrente, pero no puede ser paralelo. Por otro lado, un concurrente bien escrito el programa puede ejecutarse eficientemente en paralelo en un multiprocesador. Que la propiedad podría ser importante...
- Rob Pike -

Para entender la diferencia, recomiendo encarecidamente ver este video de Rob Pike(uno de los creadores de Golang). ' La Concurrencia No Es Paralelismo '

La programación paralela ocurre cuando el código se está ejecutando al mismo tiempo y cada ejecución es independiente de la otra. Por lo tanto, generalmente no hay una preocupación sobre las variables compartidas y tal porque eso no sucederá de manera similar.

Sin embargo, la programación concurrente consiste en que el código sea ejecutado por diferentes procesos / subprocesos que comparten variables y tales, por lo tanto, en la programación concurrente debemos establecer algún tipo de regla para decidir qué proceso / subproceso se ejecuta primero, queremos esto para que podamos estar seguros de que habrá coherencia y que podamos saber con certeza lo que sucederá. Si no hay control y todos los hilos computan al mismo tiempo y almacenan cosas en las mismas variables ¿cómo sabremos qué esperar al final? Tal vez un subproceso es más rápido que el otro, tal vez uno de los subprocesos incluso se detuvo en medio de su ejecución y otro continuó un cálculo diferente con una variable dañada(aún no completamente computada), las posibilidades son interminable. Es en estas situaciones que solemos usar programación concurrente en lugar de paralela.

Son dos frases que describen la misma cosa desde puntos de vista (muy ligeramente) diferentes. La programación paralela describe la situación desde el punto de vista del hardware there hay al menos dos procesadores (posiblemente dentro de un solo paquete físico) trabajando en un problema en paralelo. La programación concurrente es describir las cosas más desde el punto de vista del software two dos o más acciones pueden ocurrir exactamente al mismo tiempo (simultáneamente).

El problema aquí es que la gente está tratando de usar las dos frases para hacer una distinción clara cuando realmente no existe ninguna. La realidad es que la línea divisoria que están tratando de trazar ha sido borrosa e indistinta durante décadas, y se ha vuelto cada vez más borrosa con el tiempo.

Lo que están tratando de discutir es el hecho de que érase una vez, la mayoría de las computadoras tenían una sola CPU. Cuando ejecutaba varios procesos (o subprocesos) en esa sola CPU, la CPU solo estaba ejecutando realmente una instrucción de una de esas hilos a la vez. La apariencia de concurrencia era una ilusión the el cambio de CPU entre la ejecución de instrucciones de diferentes hilos lo suficientemente rápido como para la percepción humana (a la que cualquier cosa menos de 100 ms o menos parece instantánea) parecía que estaba haciendo muchas cosas a la vez.

El contraste obvio con esto es una computadora con múltiples CPU, o una CPU con múltiples núcleos, por lo que la máquina está ejecutando instrucciones de múltiples subprocesos y/o procesos exactamente al mismo tiempo tiempo; el código que ejecuta uno no puede / no tiene ningún efecto sobre el código que se ejecuta en el otro.

Ahora el problema: una distinción tan limpia casi nunca ha existido . Los diseñadores de computadoras son en realidad bastante inteligentes, por lo que notaron hace mucho tiempo que (por ejemplo) cuando necesitabas leer algunos datos de un dispositivo de E/S como un disco, tomaba un largo tiempo (en términos de ciclos de CPU) para terminar. En lugar de dejar la CPU inactiva mientras eso sucedía, descubrieron varias maneras de dejar que un proceso/hilo haga una solicitud de E/S, y dejar que el código de algún otro proceso/hilo se ejecute en la CPU mientras se completa la solicitud de E / S.

Así que, mucho antes de que las CPU multinúcleo se convirtieran en la norma, teníamos operaciones de múltiples subprocesos sucediendo en paralelo.

Eso es solo la punta del iceberg. Hace décadas, las computadoras comenzaron a proporcionar otro nivel de paralelismo también. Una vez más, siendo personas bastante inteligentes, los diseñadores de computadoras notaron que en muchos casos, tenía instrucciones que no se afectaban entre sí, por lo que era posible ejecutar más de una instrucción de la misma secuencia al mismo tiempo. Un ejemplo temprano que llegó a ser bastante conocido fue el Control Data 6600. Esta era (por un margen bastante amplio) la computadora más rápida de la tierra cuando se introdujo en 1964 and y gran parte de la misma arquitectura básica permanece en uso hoy en día. Rastreaba los recursos utilizados por cada instrucción, y tenía un conjunto de unidades de ejecución que ejecutaban las instrucciones tan pronto como los recursos de los que dependían se hicieron disponibles, muy similares al diseño de los procesadores Intel/AMD más recientes.

Pero (como los comerciales solían decir) espera that eso no es todo. Hay otro elemento de diseño para añadir aún más confusión. Se le han dado varios nombres diferentes (por ejemplo, "Hyperthreading", "SMT", "CMP"), pero todos se refieren a la misma idea básica: una CPU que puede ejecutar múltiples subprocesos simultáneamente, utilizando una combinación de algunos recursos que son independientes para cada hilo, y algunos recursos que se comparten entre los hilos. En un caso típico, esto se combina con el paralelismo a nivel de instrucción descrito anteriormente. Para ello, tenemos dos (o más) conjuntos de registros arquitectónicos. Luego tenemos un conjunto de unidades de ejecución que pueden ejecutar instrucciones tan pronto como los recursos necesarios estén disponibles. Estos a menudo se combinan bien porque las instrucciones de las corrientes separadas prácticamente nunca dependen de los mismos recursos.

Entonces, de por supuesto, llegamos a sistemas modernos con múltiples núcleos. Aquí las cosas son obvias, ¿verdad? Tenemos N (en algún lugar entre 2 y 256 más o menos, en este momento) núcleos separados, que pueden ejecutar todas las instrucciones al mismo tiempo, por lo que tenemos un caso claro de paralelismo real executing ejecutar instrucciones en un proceso/hilo no afecta la ejecución de instrucciones en otro.

Para resumir: los escenarios simples que a la gente le gusta contrastar entre recursos compartidos y recursos independientes prácticamente nunca ocurren en la vida real. Con todos los recursos compartidos, terminamos con algo como MS-DOS, donde solo podemos ejecutar un programa a la vez, y tenemos que dejar de ejecutar uno antes de que podamos ejecutar el otro. Con totalmente independiente recursos, tenemos N computadoras que ejecutan MS-DOS (sin siquiera una red para conectarlos) sin capacidad para compartir nada entre ellos en absoluto (porque si incluso podemos compartir un archivo, bueno, eso es un recurso compartido, una violación de la premisa básica de no compartir nada).

Cada caso interesante implica alguna combinación de recursos independientes y recursos compartidos. Cada computadora razonablemente moderna (y muchas que no son del todo modernas) tiene al menos alguna capacidad para llevar a cabo al menos un pocas operaciones independientes simultáneamente, y casi cualquier cosa más sofisticada que MS-DOS ha aprovechado eso al menos en cierta medida.

La división agradable y limpia entre "concurrente" y "paralelo" que a la gente le gusta dibujar simplemente no existe, y casi nunca lo ha hecho. Lo que a la gente le gusta clasificar como "concurrente" generalmente todavía implica al menos uno y a menudo más tipos diferentes de ejecución paralela. Lo que les gusta clasificar como "paralelo" a menudo implica compartir recursos y (por ejemplo) un proceso que bloquea la ejecución de otro mientras usa un recurso que se comparte entre los dos.

Las personas que tratan de establecer una clara distinción entre "paralelo" y "concurrente" están viviendo en una fantasía de computadoras que nunca existieron realmente.

Entendí que la diferencia era:

1) Concurrente-corriendo en tándem usando recursos compartidos 2) Paralelo-corriendo lado a lado usando diferentes recursos

Así que puede tener dos cosas sucediendo al mismo tiempo independientes entre sí, incluso si se unen en los puntos (2) o dos cosas que utilizan las mismas reservas a lo largo de las operaciones que se ejecutan (1).

1. Definiciones:

La programación clásica de tareas puede ser SERIAL, PARALLEL o CONCURRENT

SERIAL: El análisis muestra que las tareas DEBE SER ejecutado uno tras otro en un orden conocido de secuencia engañada O no funcionará.

Es decir: Bastante fácil, podemos vivir con esto

PARALLEL: el Análisis muestra que las tareas DEBE SER ejecuta al mismo tiempo O no funcionará.

• Cualquier fallo de cualquiera de las tareas func funcionalmente o en el tiempo will resultará en un fallo total del sistema.
• Todas las tareas deben tener un sentido común confiable del tiempo.

Es decir: Trate de evitar esto o tendremos lágrimas a la hora del té.

CONCURRENT. el Análisis muestra que hemos NO NECESITA CUIDADOS. No somos descuidados, lo hemos analizado y no lo hace matter; we cantherefore execute anytask using anyavailable facility at any time.

ES DECIR: DÍAS FELICES

A menudo la programación disponible cambios en eventos conocidos que llamé un cambio de estado.

2. Esto no es una Característica { Software | Programación} sino un enfoque de Diseño de Sistemas:

La gente a menudo piensa que se trata de software, pero es de hecho un diseño de sistemas concepto que anterior a las computadoras

Los sistemas de software fueron un poco lentos en la absorción, muy pocos lenguajes de software siquiera intentan abordar el problema.

Usted puede trate de buscar hasta el TRANSPUTER idioma occam si usted está interesado en un buen intento.

( occam tiene muchos principalmente innovadores (si no insuperable) características, incl. soporte de lenguaje explícito para PAR y SER los constructores de ejecución de piezas de código que otros lenguajes sufren principalmente de tener en la era forthcomming de Matrices de Procesadores Paralelos Masivos disponibles en los últimos años, reinventando los Transputers INMOS wheel utilizados hace más de 35 años (!!!) )

3. Lo que un buen Diseño de sistemas se encarga de cubrir:

Sucintamente, sistemas diseño aborda lo siguiente:

EL VERBO - Qué estás haciendo. ( operación o algoritmo )

EL SUSTANTIVO - ¿Qué estás haciendo a. (Data or interface)

CUANDO - Iniciación, los horarios, los cambios de estado, SERIAL, PARALLEL, CONCURRENT

DONDE - Una vez que sabes cuando las cosas suceden entonces puedes decir donde pueden suceder y no antes.

Por QUÉ - Es esta una manera de hacerlo? ¿Hay alguna otra manera? Hay una mejor manera?

.. y por último, pero no menos importante .. ¿QUÉ SUCEDE SI NO LO HACES ?

4. Ejemplos visuales de PARALELO vs SERIAL enfoques:

Reciente Arquitecturas paralelas disponibles en 2014 en acción sobre matrices de 16 -, 64 -, 1024-RISC paralelo uP-s

Cuarto de siglo volver-una parte de la verdadera historia paralela con Inmos Transputer CPU demo video de principios de la década de 1990

Buena suerte

• Concurrent programming es en un sentido general referirse a entornos en los que las tareas que definimos pueden ocurrir en cualquier orden. Una tarea puede ocurrir antes o después de otro, y algunas o todas las tareas pueden ser realizado al mismo tiempo.

• Parallel programming se refiere específicamente a la ejecución simultánea de tareas concurrentes en diferentes procesadores. Por lo tanto, todos la programación paralela es concurrente, pero no toda la programación concurrente es paralelo.

Source: PThreads Programming-A POSIX Standard for Better Multiprocessing, Buttlar, Farrell, Nichols

Aunque no está completo acuerdo sobre la distinción entre los términos paralelo y concurrente, muchos autores hacen las siguientes distinciones:

• En computación concurrente, un programa es aquel en el que múltiples tareas pueden estar en progreso en cualquier momento.
• En computación paralela, un programa es aquel en el que múltiples tareas cooperan estrechamente para resolver un problema.

Así que los programas paralelos son concurrentes, pero un programa como una multitarea el sistema operativo también es concurrente, incluso cuando se ejecuta en una máquina con solo un núcleo, ya que múltiples tareas pueden estar en progreso en cualquier momento.

Source : Una introducción a la programación paralela, Peter Pacheco