Bem, isso depende de como você define a simultaneidade.
No software do lado do servidor, simultaneidade e paralelismo são frequentemente considerados como conceitos diferentes. Em um servidor, suportar E / Ss simultâneas significa que o servidor pode atender a vários clientes executando vários fluxos correspondentes a esses clientes com apenas uma unidade de computação. Nesse contexto, paralelismo significaria que o servidor é capaz de executar várias coisas ao mesmo tempo (com várias unidades de computação), o que é diferente.
Por exemplo, um barman é capaz de cuidar de vários clientes, enquanto ele só pode preparar uma bebida de cada vez. Para que ele possa fornecer simultaneidade sem paralelismo.
Esta questão foi debatida aqui:
Qual é a diferença entre simultaneidade e paralelismo?
Veja também esta apresentação de Rob Pike.
Um programa de thread único pode definitivamente fornecer simultaneidade no nível de E / S usando um mecanismo de multiplexação de E / S (des) e um loop de eventos (que é o que Redis faz).
O paralelismo tem um custo: com os vários soquetes / múltiplos núcleos que você encontra no hardware moderno, a sincronização entre os segmentos é extremamente cara. Por outro lado, o gargalo de um mecanismo de armazenamento eficiente como o Redis geralmente é a rede, muito antes da CPU. Os loops de eventos isolados (que não requerem sincronização) são, portanto, vistos como um bom design para criar servidores eficientes e escaláveis.
O fato de as operações Redis serem atômicas é simplesmente uma consequência do loop de eventos de thread único. O ponto interessante é que a atomicidade é fornecida sem custo adicional (não requer sincronização). Ele pode ser explorado pelo usuário para implementar o bloqueio otimista e outros padrões sem pagar pela sobrecarga de sincronização.