Performance: Non-blocking threads can generally perform better than blocking threads, as they do not !need to wait for a particular event or condition to occur before continuing their execution.
Si je ne m'abuse c'est faux. Les non bloquants ont en général une meilleure bande passante serait correct, mais ils ont par contre une moins bonne latence. Les bloquants devraient, dans le cas où ils sont bloqués, être plus rapide pour traiter l'information à disposition. Comme souvent c'est un compromis.
Posté par nico4nicolas .
Évalué à 4 (+2/-0).
Dernière modification le 15 janvier 2025 à 09:43.
Question d'un ignorant : la notion de thread bloquant m'est inconnue, est-ce propre à Java ? Les références que je trouve en faisant une recherche rapide mentionnent uniquement ce langage. Dans d'autres langages, la notion de fonction bloquante m'est familière.
Posté par jseb .
Évalué à 2 (+0/-0).
Dernière modification le 15 janvier 2025 à 11:58.
J'ai lu l'article vite fait, et il donne l'exemple d'un thread qui lit complètement un fichier. Et donc bloque en théorie le programme qui utilise ce thread (j'ajoute: sauf si lui même a plusieurs threads à dispo).
Ça ne parait pas lié à Java proprement dit, c'est juste une façon d'utiliser les threads. Pourquoi pas, pour privilégier certains traitements importants. Du moment que l'interface répond toujours, au minimum (il faut donc au moins un autre thread). De toutes façons, le scheduler de l'OS va forcer un switch et ça ne doit pas bloquer la machine.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
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'article semble parler de threads bloquants alors que le propos pourrait être généralisé à un processus comme sur l'image tout en haut de la page. Je pense que cet article mélange plusieurs choses ou les nomme de façon incorrect ou qu'il y a quelque chose qui m'échappe.
Je suis d'accord, l'article n'est pas de très bonne qualité, mélanges des choses qui n'ont pas grand chose à voir. Et l'exemple en Spring Boot lance un traitement mais n'en fait jamais rien… pas vraiment le cas standard d'un API Call…
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.
On peut rajouter une couche à cela : Les "green threads" ou "light tread". Ce sont des threads en mode purement utilisateur. Lors de l'écriture des threads pour linux, il y a eu un grand débat pour finir par se décider pour un thread user == un thread kernel, c'est plus simple. Le fait de mettre plus de thread user par thread kernel redevient à la mode depuis les goroutines Golang.
Un thread user prend obligatoirement des ressources sur la machine (4ko de pile par exemple + descripteur), et donc la gestion limite à quelques millions de threads utilisables. Un thread léger est… plus léger.
Par contre tous appels bloquants kernel bloquent tous les green thread tournant sur le même thread kernel. Par exemple, un read() ou un write(), le kernel met en pause le thread qui fait cette demande pendant qu'il la traite alors que d'autres sont prêt à tourner.
Merci pour ces explications qui sont claires. Ces états (running, waiting, blocked) sont gérés par l'ordonnanceur (ou scheduler). D'un point de vue développement applicatif, je lance mon thread et je peux savoir s'il est terminé ou non pthread_join. Est-il possible d'en savoir plus ? Quand on regarde le man ps(1), on voit :
D uninterruptible sleep (usually I/O)
I idle kernel thread
R running or runnable (on run queue)
S interruptible sleep (waiting for an
event to complete)
T stopped by job control signal
t stopped by debugger during the tracing
W paging (not valid since Linux 2.6)
X dead (should never be seen)
Z defunct (“zombie”) process, terminated
but not reaped by its parent
Non, ce n'est pas lié à java, et c'est (au moins de mon point de vue de non expert) le même principe que derrière une fonction bloquante ou non. Un thread bloquant l'est parce qu'il exécute du code qui bloque le processus d’exécution tout simplement.
En gros, t'as des ressources qui sont disponibles ou non. Un thread bloquant va attendre que les ressources soient disponibles pour continuer son exécution (un fichier, un lock, l'état d'une variable), un thread non bloquant va juste remarquer qu'elles ne sont pas disponibles et puis continuer son processus, donc potentiellement faire d'autres choses en attendant.
# Exemples
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+4/-2). Dernière modification le 15 janvier 2025 à 07:52.
Ah non pas les mêmes threads.
[^] # Re: Exemples
Posté par jtremesay (site web personnel) . Évalué à 5 (+3/-0).
Mon lien est bien une réaction au lien précédent :)
J’ai étais déçu de voir que ça parlait de Mastodon et Méta et non pas de fils d’exécutions :(
# bande passante / latence
Posté par Elfir3 . Évalué à 3 (+1/-0).
Si je ne m'abuse c'est faux. Les non bloquants ont en général une meilleure bande passante serait correct, mais ils ont par contre une moins bonne latence. Les bloquants devraient, dans le cas où ils sont bloqués, être plus rapide pour traiter l'information à disposition. Comme souvent c'est un compromis.
Je me suis arrêté là..
[^] # Re: bande passante / latence
Posté par nico4nicolas . Évalué à 4 (+2/-0). Dernière modification le 15 janvier 2025 à 09:43.
Question d'un ignorant : la notion de thread bloquant m'est inconnue, est-ce propre à Java ? Les références que je trouve en faisant une recherche rapide mentionnent uniquement ce langage. Dans d'autres langages, la notion de fonction bloquante m'est familière.
[^] # Re: bande passante / latence
Posté par jseb . Évalué à 2 (+0/-0). Dernière modification le 15 janvier 2025 à 11:58.
J'ai lu l'article vite fait, et il donne l'exemple d'un thread qui lit complètement un fichier. Et donc bloque en théorie le programme qui utilise ce thread (j'ajoute: sauf si lui même a plusieurs threads à dispo).
Ça ne parait pas lié à Java proprement dit, c'est juste une façon d'utiliser les threads. Pourquoi pas, pour privilégier certains traitements importants. Du moment que l'interface répond toujours, au minimum (il faut donc au moins un autre thread). De toutes façons, le scheduler de l'OS va forcer un switch et ça ne doit pas bloquer la machine.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: bande passante / latence
Posté par nico4nicolas . Évalué à 3 (+1/-0).
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'article semble parler de threads bloquants alors que le propos pourrait être généralisé à un processus comme sur l'image tout en haut de la page. Je pense que cet article mélange plusieurs choses ou les nomme de façon incorrect ou qu'il y a quelque chose qui m'échappe.
[^] # Re: bande passante / latence
Posté par aiolos . Évalué à 4 (+2/-0).
Je suis d'accord, l'article n'est pas de très bonne qualité, mélanges des choses qui n'ont pas grand chose à voir. Et l'exemple en Spring Boot lance un traitement mais n'en fait jamais rien… pas vraiment le cas standard d'un API Call…
[^] # Re: bande passante / latence
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
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.
[^] # Re: bande passante / latence
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0).
On peut rajouter une couche à cela : Les "green threads" ou "light tread". Ce sont des threads en mode purement utilisateur. Lors de l'écriture des threads pour linux, il y a eu un grand débat pour finir par se décider pour un thread user == un thread kernel, c'est plus simple. Le fait de mettre plus de thread user par thread kernel redevient à la mode depuis les goroutines Golang.
Un thread user prend obligatoirement des ressources sur la machine (4ko de pile par exemple + descripteur), et donc la gestion limite à quelques millions de threads utilisables. Un thread léger est… plus léger.
Par contre tous appels bloquants kernel bloquent tous les green thread tournant sur le même thread kernel. Par exemple, un read() ou un write(), le kernel met en pause le thread qui fait cette demande pendant qu'il la traite alors que d'autres sont prêt à tourner.
"La première sécurité est la liberté"
[^] # Re: bande passante / latence
Posté par nico4nicolas . Évalué à 3 (+1/-0).
Merci pour ces explications qui sont claires. Ces états (running, waiting, blocked) sont gérés par l'ordonnanceur (ou scheduler). D'un point de vue développement applicatif, je lance mon thread et je peux savoir s'il est terminé ou non pthread_join. Est-il possible d'en savoir plus ? Quand on regarde le man ps(1), on voit :
[^] # Re: bande passante / latence
Posté par bnurb . Évalué à 3 (+2/-0).
L'allocation mémoire peut être bloquante aussi. Donc les new ou les malloc dans les threads peuvent miner la parallélisation d'un algo.
[^] # Re: bande passante / latence
Posté par Elfir3 . Évalué à 3 (+1/-0).
Non, ce n'est pas lié à java, et c'est (au moins de mon point de vue de non expert) le même principe que derrière une fonction bloquante ou non. Un thread bloquant l'est parce qu'il exécute du code qui bloque le processus d’exécution tout simplement.
En gros, t'as des ressources qui sont disponibles ou non. Un thread bloquant va attendre que les ressources soient disponibles pour continuer son exécution (un fichier, un lock, l'état d'une variable), un thread non bloquant va juste remarquer qu'elles ne sont pas disponibles et puis continuer son processus, donc potentiellement faire d'autres choses en attendant.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.