Beh, dipende da come definisci la concorrenza.
Nel software lato server, concorrenza e parallelismo sono spesso considerati concetti diversi. In un server, il supporto di I/O simultanei significa che il server è in grado di servire diversi client eseguendo diversi flussi corrispondenti a quei client con una sola unità di calcolo. In questo contesto, il parallelismo significherebbe che il server è in grado di eseguire più cose contemporaneamente (con più unità di calcolo), il che è diverso.
Ad esempio un barista è in grado di prendersi cura di più clienti mentre può preparare solo una bevanda alla volta. Quindi può fornire concorrenza senza parallelismo.
Questa domanda è stata discussa qui:qual è la differenza tra concorrenza e parallelismo?
Vedi anche questa presentazione di Rob Pike.
Un programma a thread singolo può sicuramente fornire concorrenza a livello di I/O utilizzando un meccanismo di (de)multiplexing I/O e un ciclo di eventi (che è ciò che fa Redis).
Il parallelismo ha un costo:con i socket multipli/core multipli che puoi trovare sull'hardware moderno, la sincronizzazione tra i thread è estremamente costosa. D'altra parte, il collo di bottiglia di uno storage engine efficiente come Redis è molto spesso la rete, ben prima della CPU. I loop di eventi isolati (che non richiedono sincronizzazione) sono quindi visti come un buon progetto per costruire server efficienti e scalabili.
Il fatto che le operazioni Redis siano atomiche è semplicemente una conseguenza del ciclo di eventi a thread singolo. Il punto interessante è che l'atomicità è fornita senza costi aggiuntivi (non richiede sincronizzazione). Può essere sfruttato dall'utente per implementare il blocco ottimistico e altri modelli senza pagare il sovraccarico di sincronizzazione.
