Dans un sens simple, vous pouvez considérer un fil comme un autre pointeur d'instruction dans le processus actuel. En d'autres termes, il dirige l'IP d'un autre processeur vers un code dans le même exécutable. Ainsi, au lieu d'avoir un pointeur d'instruction qui se déplace dans le code, il y a deux ou plusieurs IP qui exécutent des instructions. à partir du même exécutable et du même espace d'adressage simultanément.
Rappelez-vous que l'exécutable a son propre espace d'adressage avec des données / pile etc... Maintenant que deux instructions ou plus sont exécutées simultanément, vous pouvez imaginer ce qui se passe lorsque plus d'une instruction veut lire/écrire à la même adresse mémoire en même temps.
Le hic, c'est que les fils fonctionnent dans le cadre de la processus et ne bénéficient pas de mécanismes de protection de la part du processeur que les processeurs complets processus sont. (La bifurcation d'un processus sous UNIX est une pratique standard et crée simplement un autre processus).
Les threads incontrôlables peuvent consommer des cycles CPU, consommer de la RAM, provoquer des exceptions, etc. etc. et la seule façon de les arrêter est de demander au planificateur de processus du système d'exploitation de terminer de force le thread en annulant son pointeur d'instruction (c'est-à-dire en arrêtant l'exécution). Si vous demandez à une unité centrale de cesser d'exécuter une séquence d'instructions, qu'arrive-t-il aux ressources qui ont été allouées ou qui sont utilisées par ces instructions ? Sont-elles laissées dans un état stable ? Sont-elles correctement libérées ? etc...
Donc, oui, les threads demandent plus de réflexion et de responsabilité que l'exécution d'un processus en raison des ressources partagées.
