Qu'entend-on par «blocage de l'appel système»?
Quelle est la signification de "blocage de l'appel système"?
Dans mon cours sur les systèmes d'exploitation, nous étudions la programmation multithread. Je ne sais pas ce que l'on entend lorsque je lis dans mon manuel "cela peut permettre à un autre thread de s'exécuter lorsqu'un thread effectue un appel système bloquant"
Un appel système bloquant est un appel qui doit attendre la fin de l'action. read() serait un bon exemple - si aucune entrée n'est prête, elle restera là et attendra jusqu'à ce que certaines (à condition que vous ne l'ayez pas définie sur non bloquante, bien sûr, auquel cas elle ne le ferait pas pas un appel système bloquant). Évidemment, pendant qu'un thread attend un appel système bloquant, un autre thread peut être en train de faire autre chose.
Pour un appel système bloquant, l'appelant ne peut rien faire avant le retour de l'appel système. Si l'appel système peut être long (par exemple, impliquer le fichier IO ou IO réseau), cela peut être une mauvaise chose (par exemple, imaginez un utilisateur frustré martelant un bouton "Annuler" dans une application qui ne fonctionne pas). répondre parce que ce thread est bloqué en attendant un paquet du réseau qui n'arrive pas. Pour contourner ce problème (pour faire un travail utile pendant que vous attendez un appel système bloquant pour revenir), vous pouvez utiliser des threads - pendant qu'un thread est bloqué l'autre thread/s peut continuer à faire un travail utile.
L'alternative est les appels système non bloquants. Dans ce cas, l'appel système revient (presque) immédiatement. Pour les appels système longs, le résultat de l'appel système est soit envoyé à l'appelant ultérieurement (par exemple sous la forme d'une sorte d'événement, de message ou de signal), soit interrogé par l'appelant ultérieurement. Cela vous permet d'avoir un seul thread en attente de nombreux appels système longs et différents à terminer en même temps; et évite les tracas des threads (et le verrouillage, les conditions de course, la surcharge des commutateurs de threads, etc.). Cependant, cela augmente également les tracas liés à l'obtention et à la gestion des résultats de l'appel système.
Il est (presque toujours) possible d'écrire un wrapper non bloquant autour d'un appel système bloquant; où l'encapsuleur génère un thread et retourne (presque) immédiatement, et le thread généré effectue l'appel système de blocage et envoie les résultats de l'appel système à l'appelant d'origine ou les stocke où l'appelant d'origine peut les interroger.
Il est également (presque toujours) possible d'écrire un wrapper bloquant autour d'un appel système non bloquant; où l'encapsuleur fait l'appel système et attend les résultats avant de revenir.
Je suggérerais de lire ce texte très court: http://files.mkgnu.net/files/upstare/UPSTARE_RELEASE_0-12-8/manual/html-multi/x755.html En particulier vous pouvez y lire pourquoi le blocage des appels système peut être un problème avec les threads, pas seulement avec les processus simultanés:
Cela est particulièrement problématique pour les applications multithreads car un blocage de thread sur un appel système peut retarder indéfiniment la mise à jour du code d'un autre thread.
J'espère que ça aide.