Bem, depende de como você define a simultaneidade.

No software do lado do servidor, a simultaneidade e o paralelismo são frequentemente considerados como conceitos diferentes. Em um servidor, o suporte a E/Ss simultâneas significa que o servidor é capaz de atender 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 realizar 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 por vez. Assim, ele pode 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 (des)multiplexação de E/S e um loop de eventos (que é o que o Redis faz).

O paralelismo tem um custo:com os vários soquetes/múltiplos núcleos encontrados em hardware moderno, a sincronização entre threads é extremamente cara. Por outro lado, o gargalo de um mecanismo de armazenamento eficiente como o Redis é muitas vezes a rede, bem antes da CPU. Os loops de eventos isolados (que não requerem sincronização) são, portanto, vistos como um bom design para construir servidores eficientes e escaláveis.

O fato de as operações do Redis serem atômicas é simplesmente uma consequência do loop de eventos de thread único. O ponto interessante é que a atomicidade é fornecida sem custo extra (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.