Eh bien cela dépend de comment vous définissez la simultanéité.
Dans logiciel côté serveur, la concurrence et parallélisme sont souvent considérés comme des concepts différents. Dans un serveur, l'appui simultané des e/s signifie que le serveur est capable de servir plusieurs clients par l'exécution de plusieurs flux correspondant à ces clients avec une seule unité de calcul. Dans ce contexte, le parallélisme voudrait dire que le serveur est capable d'effectuer plusieurs choses en même temps (avec plusieurs unités de calcul), ce qui est différent.
Par exemple, un barman est en mesure de s'occuper de plusieurs clients, alors qu'il ne peut pas préparer une boisson à la fois. Donc, il peut fournir la simultanéité sans parallélisme.
Cette question a été débattue ici:
La simultanéité vs Parallélisme - Quelle est la différence?
Voir également cette présentation de Rob Pike.
Un single-threaded programme peut certainement fournit la simultanéité de l'I/O niveau à l'aide d'un I/O (de)mécanisme de multiplexage et une boucle (qui est ce que le Redis).
Le parallélisme a un coût: les prises multiples/multiples coeurs que vous pouvez trouver sur le matériel moderne, la synchronisation entre les threads est extrêmement coûteux. D'autre part, le goulot d'étranglement de l'efficacité du moteur de stockage comme le Redis c'est très souvent le réseau, bien avant de l'UC. Événement isolé boucles (qui ne nécessitent pas de synchronisation) sont donc considérés comme un bon design pour construire efficace, évolutive des serveurs.
Le fait que le Redis opérations atomiques est simplement une conséquence de la single-threaded boucle d'événements. Le point intéressant est l'atomicité est fourni sans coût supplémentaire (il ne nécessite pas de synchronisation). Il peut être exploité par l'utilisateur de mettre en œuvre le verrouillage optimiste et d'autres modèles sans avoir à payer pour la synchronisation des frais généraux.
