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é à 3 (+1/-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
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é à 3 (+2/-2). Dernière modification le 15 janvier 2025 à 07:52.
Ah non pas les mêmes threads.
# bande passante / latence
Posté par Elfir3 . Évalué à 2 (+0/-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é à 3 (+1/-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 Elfir3 . Évalué à 2 (+0/-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.