C'est ce que je comprends mais quelle est la spécificité d'un thread ? C'est le cas pour une fonction bloquante mais Java semble avoir un état du thread à la valeur BLOCKED. Ca semble être uniquement sur attente d'un verrou (mutex ?
l'état "bloqué" existe dans tous les ordonnanceurs. Un thread a généralement 3 états possibles:
en cours d'exéctution
en attente de resource cpu (thread "prêt")
en attented'une autre ressource (thread bloqué)
le troisième cas sera une attente de mutex, mais aussi l'appel de certaines fonctions, comme un read() sur un socket qui va attendre que des données soient reçues sur ce socket, un read sur un fichier qui va attendre un accès disque, un sleep(] qui va attendre une durée fixe, etc.
lorsqu'un thread effectue l'une de ces opérations, il va libérer le chu pour qu'un autre thread puisse prendre la main. Lorsque la resource devient disponible (un autre thread libère le mutex, le socket a reçu des données, ...), le thread redevient "ready" mais n'obtient pas forcément immédiatement l'accès au cpu. On a donc une double attente: pour la ressource bloquante puis pour le cpu, ce qui augmente la latence.
Une approche non bloquante consiste à faire en sorte que le thread ne libère jamais le cpu. Par exemple, un thread qui surveille un grand nombre de ressources (via select(), poll(), epoll() ou kqueue() par exemple) aura des chances d'avoir toujours quelque chose à faire, ou encore, si on s'attend à une durée d'attente très courte pour une ressource, on peut faire une attente active: une boucle qui teste en permanence si la ressource devient disponible. Ainsi, le thread ne libère pas le cpu pendant l'attente d'une autre ressource. La latence est réduite, mais en contrepartie, le cpu n'est pas libéré alors qu'il aurait pu servir à autre chose: le débit de traitement est réduit.
[^] # Re: bande passante / latence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Blocking and non-blocking threads. Évalué à 6.
l'état "bloqué" existe dans tous les ordonnanceurs. Un thread a généralement 3 états possibles:
le troisième cas sera une attente de mutex, mais aussi l'appel de certaines fonctions, comme un read() sur un socket qui va attendre que des données soient reçues sur ce socket, un read sur un fichier qui va attendre un accès disque, un sleep(] qui va attendre une durée fixe, etc.
lorsqu'un thread effectue l'une de ces opérations, il va libérer le chu pour qu'un autre thread puisse prendre la main. Lorsque la resource devient disponible (un autre thread libère le mutex, le socket a reçu des données, ...), le thread redevient "ready" mais n'obtient pas forcément immédiatement l'accès au cpu. On a donc une double attente: pour la ressource bloquante puis pour le cpu, ce qui augmente la latence.
Une approche non bloquante consiste à faire en sorte que le thread ne libère jamais le cpu. Par exemple, un thread qui surveille un grand nombre de ressources (via select(), poll(), epoll() ou kqueue() par exemple) aura des chances d'avoir toujours quelque chose à faire, ou encore, si on s'attend à une durée d'attente très courte pour une ressource, on peut faire une attente active: une boucle qui teste en permanence si la ressource devient disponible. Ainsi, le thread ne libère pas le cpu pendant l'attente d'une autre ressource. La latence est réduite, mais en contrepartie, le cpu n'est pas libéré alors qu'il aurait pu servir à autre chose: le débit de traitement est réduit.