Ca n'a rien de bizarre, c'est la meme chose sur toutes les plateformes.
Un thread qui viendrait sur le CPU ou une autre appli tourne, c'est que le scheduler a decide qu'il etait prioritaire sur l'appli qui tournait, donc il a une tres bonne raison de tourner. Si tu veux pas que ca arrive c'est tres simple: tu augmentes la priorite de l'application a laquelle tu tiens.
Un autre truc qui est lie mais un peu different c'est l'affinite d'un thread/process a un CPU:
- soft affinity: le thread tournera autant que possible toujours sur le(s) meme(s) CPU mais c'est pas garanti, ca permet au scheduler de mettre le thread sur un autre CPU si le CPU "elu" est tres occupe et qu'un autre est libre
- hard affinity: le thread est assure qu'il tournera toujours sur le(s) meme(s) CPU quoi qu'il arrive, ca peut servir pour certaines applications tres specifiques.
L'avantage ici c'est qu'il n'y a pas besoin de flusher/reloader les caches des CPU car les threads sont toujours sur le meme CPU.
Maintenant un des avantages des LWP c'est justement qu'une appli "mal eduquee" qui creerait 200 threads ne s'approprierait pas le CPU pour autant, car les threads seraient schedules dans 10 "threads normaux" qui eux sont schedules par le scheduler du kernel, resultat au lieu que le scheduler partage le temps dispo entre 200 + x threads, il le partage entre 10 +x threads, et les 10 threads partagent leur temps entre les 20 LWP de chaque thread.
[^] # Re: Autres applis et pthreads
Posté par pasBill pasGates . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 0.
Un thread qui viendrait sur le CPU ou une autre appli tourne, c'est que le scheduler a decide qu'il etait prioritaire sur l'appli qui tournait, donc il a une tres bonne raison de tourner. Si tu veux pas que ca arrive c'est tres simple: tu augmentes la priorite de l'application a laquelle tu tiens.
Un autre truc qui est lie mais un peu different c'est l'affinite d'un thread/process a un CPU:
- soft affinity: le thread tournera autant que possible toujours sur le(s) meme(s) CPU mais c'est pas garanti, ca permet au scheduler de mettre le thread sur un autre CPU si le CPU "elu" est tres occupe et qu'un autre est libre
- hard affinity: le thread est assure qu'il tournera toujours sur le(s) meme(s) CPU quoi qu'il arrive, ca peut servir pour certaines applications tres specifiques.
L'avantage ici c'est qu'il n'y a pas besoin de flusher/reloader les caches des CPU car les threads sont toujours sur le meme CPU.
Maintenant un des avantages des LWP c'est justement qu'une appli "mal eduquee" qui creerait 200 threads ne s'approprierait pas le CPU pour autant, car les threads seraient schedules dans 10 "threads normaux" qui eux sont schedules par le scheduler du kernel, resultat au lieu que le scheduler partage le temps dispo entre 200 + x threads, il le partage entre 10 +x threads, et les 10 threads partagent leur temps entre les 20 LWP de chaque thread.