Bueno, depende de cómo se defina la concurrencia.
En el software del lado del servidor, la concurrencia y el paralelismo a menudo se consideran conceptos diferentes. En un servidor, admitir E / S concurrentes significa que el servidor puede servir a varios clientes mediante la ejecución de varios flujos correspondientes a esos clientes con una sola unidad de cálculo. En este contexto, el paralelismo significaría que el servidor puede realizar varias cosas al mismo tiempo (con múltiples unidades de cálculo), lo cual es diferente.
Por ejemplo, un cantinero puede cuidar a varios clientes mientras que solo puede preparar una bebida a la vez. Entonces él puede proporcionar concurrencia sin paralelismo.
Esta pregunta se ha debatido aquí:
¿Cuál es la diferencia entre concurrencia y paralelismo?
Vea también esta presentación de Rob Pike.
Un programa de un solo subproceso definitivamente puede proporcionar concurrencia en el nivel de E / S mediante el uso de un mecanismo de multiplexación (des) de E / S y un bucle de eventos (que es lo que hace Redis).
El paralelismo tiene un costo: con los múltiples sockets / múltiples núcleos que puede encontrar en el hardware moderno, la sincronización entre hilos es extremadamente costosa. Por otro lado, el cuello de botella de un motor de almacenamiento eficiente como Redis es muy a menudo la red, mucho antes que la CPU. Por lo tanto, los bucles de eventos aislados (que no requieren sincronización) se consideran un buen diseño para construir servidores eficientes y escalables.
El hecho de que las operaciones de Redis sean atómicas es simplemente una consecuencia del bucle de eventos de un solo subproceso. El punto interesante es que la atomicidad se proporciona sin costo adicional (no requiere sincronización). El usuario puede explotarlo para implementar un bloqueo optimista y otros patrones sin pagar la sobrecarga de sincronización.