Comment expliqueriez-vous un simple mortel sur le blocage de l'IO et de l'IO non bloquante? J'ai découvert que ces concepts ne sont pas très clairs parmi beaucoup de programmeurs américains.
3 Réponses :
Blocage d'E / S signifie que l'exécution du programme est mise en attente pendant que les E / S se déroulent. Donc, le programme attend jusqu'à ce que l'E / S soit terminée, puis continue son exécution. Dans les E / S non bloquantes, le programme peut se poursuivre pendant les opérations d'E / S.
... et est la notifiée via un rappel lorsque l'opération IO est terminée. Cela vous oblige à concevoir vos programmes différemment, mais les rendre mieux performer.
@ Lex, n'importe quel exemple de fonctionnement de blocage et de non-bloque? Merci.
@etc_passwd en JS c'est simple à comprendre; Un appel à alerte (); bloque, car l'exécution est enfilée jusqu'à ce que l'utilisateur clique sur OK. Un appel AJAX est non bloqué, l'exécution de se poursuit alors que la demande HTTP est en cours d'envoi.
Dit simplement. Les E / S non bloquants (asynchrones) permettent d'effectuer d'autres opérations à effectuer pendant que sa chose et son blocage d'E / S bloquerait d'autres opérations
C'est une question de concurrence. Dans le cas normal, une fois qu'un noyau OS reçoit un I / O op d'un programme utilisateur, ce programme ne fonctionne plus que l'opération d'E / S se termine. D'autres programmes deviennent généralement programmés entre-temps.
Cela résout beaucoup de petits problèmes. Par exemple, comment un programme sait-il combien d'octets ont été lus à moins que les E / S ne soient terminés lorsque le En fin de compte, il s'agit de:
La question compliquée est compliquée par les efforts visant à planifier des programmes multithreads lorsque les E / S pourraient éventuellement bloquer un seul fil, mais c'est une question différente ... lue (2) retourne? Comment savoir si cela peut réutiliser un buffer écrire (2) si l'opération est toujours en cours lorsque écriture (2) retourne? Évidemment, une interface plus complexe est nécessaire pour des E / S extrêmement asynchrones.