thread ce n'est un pas processus
bonjour alex
ce qu'a dit pol est valable à l'interieur d'un processus.
Ce que je voulais dire va plus en profondeur dans l'utilisation des threads par le systeme lui-meme.
Car windows fait du multitache.
Il alloue par defaut un thread principal (petite unite de code) à notre "insu" à chaque processus(application) .
Ensuite il bascule ("switching") constamment d'un processus à l'autre en passant l'execution de code d'un thread 1(application1),à thread2(application2).
ce qui fait schematiquement on a ceci:
appli1->thread principal1(un petit bout de code =A)
appli2->thread principal2(un petit bout de code =B)
appli3->thread principal3(un petit bout de code =C)
Execution Phase 0:
Execute A
Execute B
Execute C
Phase 1:Bascule (suite du code A,de B,de C)
Execute A
Execute B
Execute C
Phase 2:Bascule(idem...)
Execute A
Execute B
Execute C
..............
Phase N: fin ..
Maintenant quand Alex introduit mettons un thread X dans Appli1(A) on a ceci:
Execution Phase 0:
Execute A
Execute X
Execute B
Execute C
Phase 1:Bascule (suite du code A,de B, de C,de X)
Execute A
Execute X
Execute B
Execute C
l'avantage c'est que le code de ta procedure va s'inscruster à toute les phase de la queue d'execution des threads au lieu que par exemple en code normal il doit attendre la phase mettons 100 pour etre gere à l'interieur de A.
si tu veux le system regarde les processus comme des "demandeurs d'execution" et pour cela il leur affecte chacun une portion de temps qui correspond à une portion de code(thread) et ensuite il les sert à tour de role.
quand tu cree un thread tu viens d'inserer dans cette chaine de threads.
En resume c'est un abus de language "commode" de dire qu'une application s'execute en fait windows n'execute reellement que des threads.
Je n'ai pas voulu parler des apartments ("cloison de thread" qui serve à cloisonner les donnees propres à chaque thread et inaccessible aux threads)
bon code ......
