Qu’entend-on par «appel système bloquant»?

Quel est le sens de “appel système bloquant”?

Dans mon cours sur les systèmes d’exploitation, nous étudions la programmation multithread. Je ne sais pas ce que l’on veut dire quand 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 que l’action puisse être terminée. read() serait un bon exemple – si aucune entrée n’est prête, elle restra en attente jusqu’à ce que certaines le soient (à condition que vous n’ayez pas défini le blocage, bien sûr, auquel cas ce ne serait pas un blocage de l’appel système). Évidemment, lorsqu’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 jusqu’à ce que l’appel système revienne. Si l’appel système peut être long (par exemple, impliquer un fichier IO ou un réseau IO), cela peut être une mauvaise chose (par exemple, imaginez un utilisateur frustré qui enfonce un bouton “Annuler” dans une application qui ne répond pas car ce thread est bloqué dans l’attente d’une paquet du réseau qui n’arrive pas). Pour contourner ce problème (pour effectuer un travail utile en attendant qu’un appel système bloquant soit renvoyé), vous pouvez utiliser des threads: lorsqu’un thread est bloqué, les autres threads peuvent continuer à effectuer 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’un événement ou d’un message ou d’un 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 longs en même temps; et évite les tracas de threads (et le locking, les conditions de concurrence, les frais généraux des commutateurs de threads, etc.). Cependant, cela augmente également les tracas liés à l’obtention et au traitement 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 revient (presque) immédiatement, et le thread généré effectue l’appel système bloquant et envoie les résultats de l’appel système à l’appelant d’origine ou les stocke à l’endroit où l’appelant initial peut les rechercher.

Il est également (presque toujours) possible d’écrire un wrapper bloquant autour d’un appel système non bloquant; où le wrapper appelle le système et attend les résultats avant de le retourner.

Je suggérerais de lire ce très court texte: http://files.mkgnu.net/files/upstare/UPSTARE_RELEASE_0-12-8/manual/html-multi/x755.html Vous pouvez notamment lire pourquoi le système de blocage les appels peuvent être un problème avec les threads, pas seulement avec les processus simultanés:

Cela est particulièrement problématique pour les applications multithreads puisqu’un blocage d’un 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.