Concurrence, parallélisme, asynchrone, non-bloquant et concepts associés

J’ai essayé de couvrir un large éventail de sujets, d’un simple rappel de terminologie jusqu’au graphisme et aux semi-conducteurs.

1. Terminologie
   • Concurrence / parallélisme
   • Asynchrone / non-bloquant
   • Préemptif / non préemptif
2. Système d’exploitation et processeur
   • Système d’exploitation
   • Processeur
3. Coroutines et fibres
   • Fibres
   • Coroutines
4. Générateurs, Async/Await, continuations
   • Générateurs
   • Async / Await
   • Continuations
5. Promise et Future
6. Multiplexage d’E/S
   • Multiplexage
   • Sockets
   • Modèles d’E/S
7. Ring buffer, modèles d’E/S récents, LMAX Disruptor
   • Ring buffer
   • Modèles d’E/S récents
   • LMAX Disruptor
8. Primitives de synchronisation
   • Pourquoi elles sont nécessaires
   • Thread safety
   • Spinlock
   • Mutex
   • Sémaphore
   • STM
   • GIL
9. Approches d’autres langages de script et motifs Reactor/Proactor
   • Ractor (Ruby)
   • Node.js (motif Reactor)
   • Motif Proactor
10. CSP et acteurs
    • CSP
    • Acteurs
11. Green threads, goroutines et technologies modernes de runtime asynchrone
    • Green threads
    • Runtimes CSP récents
    • Runtimes acteur récents
12. Parallélisme
    • SIMD et pipelining
    • OpenMP & MPI
    • Techniques de parallélisme récentes
    • Architecture lambda
13. GPU
    • Pipeline et shaders
    • Moniteur
    • Buffering
    • Synchronisation verticale
    • Frame pacing et beam racing
    • Compositeur
    • API / bibliothèques graphiques
14. Autres puces
    • Vue d’ensemble
    • DSP
    • FPGA
    • TPU
15. Références

[roxie]

Dans le synchrone et l'asynchrone, qui vérifie que la tâche est terminée ?
Dans le blocking et le non-blocking, a-t-on le contrôle ?

Je vois cette formulation répétée à l'identique sur d'innombrables blogs, et je me demande d'où elle vient à l'origine.

La plupart des blogs sont trop occupés à se citer les uns les autres pour que l'on puisse deviner le texte source, et la seule chose que j'ai à peu près trouvée, c'est la documentation AIO d'IBM. Mais j'ai l'impression qu'elle ne parle que de l'IO du kernel. Et j'ai aussi entendu dire que cette manière de distinguer les concepts est elle-même controversée.

Est-ce un critère de jugement faisant autorité ?

[alstjr7375]

Pour commencer, on peut sans doute s’appuyer sur la logique des circuits pour distinguer synchrone et asynchrone.
Les circuits synchrones utilisent une horloge pour le timing, tandis que les circuits asynchrones sont déclenchés par des événements ou d’autres entrées.
Autrement dit, il ne semble pas exagéré de définir une API asynchrone comme un mécanisme également déclenché par un callback ou un équivalent.
https://developer.mozilla.org/en-US/docs/…

Pour les API bloquantes/non bloquantes, la définition la plus appropriée est de savoir s’il faut nécessairement attendre la fin du traitement.
Cela dit, comme il faut une implémentation où la fonction appelée garde le contrôle pour éviter cette attente, c’est sans doute pour cela qu’on l’explique souvent de cette manière.
https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/

J’avais omis ce point pour rester bref, mais je vais essayer de l’ajouter également.

[roxie]

Je suis d’accord avec tout ce que vous avez écrit. En revanche, j’ai encore du mal à être vraiment certain qu’il faille représenter ces deux axes de référence sur une coupe en quadrants, qu’on puisse le faire, et qu’ils se distinguent de manière pertinente. Pour moi, Blocking et Sync partagent conceptuellement 90 % du même contexte. Il en va de même pour Non-Blocking & Async.

[alstjr7375]

On voit souvent Blocking-Sync et Non-Blocking-Async utilisés ensemble, mais il y a des cas où il faut les distinguer.

• Blocking-Async : multiplexage d’E/S comme select
• Non-Blocking-Sync : polling de données

C’est pourquoi je pense au contraire qu’il est juste de les distinguer dans l’usage.

[roxie]

J’ai l’impression que j’ai du mal à adhérer à vos exemples, car je n’en ai presque aucune compréhension.

Dans cet article, https://incredible-larva.tistory.com/entry/IO-Multiplexing-Examen-approfondi-1re-partie, c’est expliqué ainsi :

En fin de compte, c’est le processus utilisateur qui a demandé select qui regarde la valeur de retour pour déterminer s’il faut effectuer un traitement ultérieur. Comme plusieurs requêtes d’I/O arrivant de manière imprévisible sont gérées en même temps, certains considèrent cela comme asynchrone, mais en réalité chaque opération d’I/O individuelle présente un comportement synchrone.

J’aimerais savoir quelle est votre opinion à ce sujet. En réalité, à ce stade, j’ai eu le sentiment que cette classification en 2x2 n’avait plus vraiment de sens. J’ai l’impression que les interprétations varient selon les domaines et les points de vue.

[alstjr7375]

Ensuite, lorsqu'on attend la réponse du kernel, un signal de callback indiquant que la valeur de résultat est prête arrive depuis le kernel, et le processus utilisateur montre qu'il copie les données dans son propre buffer.

Comme cette partie repose sur un mode de déclenchement par callback, comme vous l'avez accepté plus haut, si l'on devait absolument la distinguer/la définir, il semblerait plus juste de l'appeler Blocking-Async.
Selon le point de vue adopté, je pense qu'il peut y avoir des cas qui paraissent ambigus.

Cependant, le polling est un exemple clair :
https://en.wikipedia.org/wiki/Polling_(computer_science)

Dans le cas du polling, on vérifie de manière répétée si les données sont prêtes, c'est donc un exemple approprié de Sync-Blocking.

[wonkwh]

Waouh, merci pour cette excellente ressource.

[kayws426]

J’ai bien aimé la lecture !

[bus710]

Le défilement n’en finit pas, haha.
Je pense qu’un livre intitulé "7 modèles de concurrence", qui traite de sujets similaires, vaut le coup d’être lu au moins une fois.

[alstjr7375]

En comparant les tables des matières, ça se ressemble.
Ça a l'air d'être un bon livre.