Si tes estimations sont exactes, c'est en effet un scheduler interne performant.
Mais faire du sous-scheduling n'est vraiment utile que quand les flux concurents s'échangent en permanence de touts petits bouts de données. Dans le cas de nombreux algorithmes où des processus s'échangent de gros blocs par pipe ou socket, le principal gaspillage est la recopie de ces blocs, évitable par shm.
En attendant que mon reve se réalise, avoir des threads avec des variables privées protégées par sigsegv, je pense qu'il y a plusieurs niveaux de compromis entre la sécurité et les performances:
1. Pour la plupart des programmes d'un Unix qui passent l'essentiel du temps à dormir, il n'y a clairement pas besoin de s'embetter avec des threads. Ni avec les shm.
2. Pour les programmes plus gourmands et qui communiquent habituellement par sockets ou pipe, un shm peut nettement améliorer les performances en évitant les recopies userspace/kernelspace.
3. Quand on veut des bêtes de course fiables (genre les serveurs web Zeus, ou thttpd/mathopd en libre) on peut éventuellement avoir recours à quelques taches ou quelques process (en nombre suffisant pour faire travailler tous les procs d'un SMP), mais surtout à select pour éviter des taches/process inutiles.
La séparation des privilèges, qui nécessite la séparation des process, peut aider à avoir bon niveau de sécurité, malgré une concurence massive.
Ou, si on est prêt à se casser la tête pour démontrer l'absence de tout overflow dans un programme concurent (bonne chance), faire du multithread masssif. Avoir des variables read-only protégées par mprotect peut aider un peu dans ce cas.
4. Enfin quand la fiabilité/sécurité est peu importante, mais la consommation CPU grosse (streams vidéos, jeux locaux ou en réseau...) alors faire du multithread sans démonstration, donc obligatoirement buggé vu la complexité pour gérer des threads.
[^] # scheduler intra-processus, voir plus haut, sécurité/rapidité
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Si tes estimations sont exactes, c'est en effet un scheduler interne performant.
Mais faire du sous-scheduling n'est vraiment utile que quand les flux concurents s'échangent en permanence de touts petits bouts de données. Dans le cas de nombreux algorithmes où des processus s'échangent de gros blocs par pipe ou socket, le principal gaspillage est la recopie de ces blocs, évitable par shm.
En attendant que mon reve se réalise, avoir des threads avec des variables privées protégées par sigsegv, je pense qu'il y a plusieurs niveaux de compromis entre la sécurité et les performances:
1. Pour la plupart des programmes d'un Unix qui passent l'essentiel du temps à dormir, il n'y a clairement pas besoin de s'embetter avec des threads. Ni avec les shm.
2. Pour les programmes plus gourmands et qui communiquent habituellement par sockets ou pipe, un shm peut nettement améliorer les performances en évitant les recopies userspace/kernelspace.
3. Quand on veut des bêtes de course fiables (genre les serveurs web Zeus, ou thttpd/mathopd en libre) on peut éventuellement avoir recours à quelques taches ou quelques process (en nombre suffisant pour faire travailler tous les procs d'un SMP), mais surtout à select pour éviter des taches/process inutiles.
La séparation des privilèges, qui nécessite la séparation des process, peut aider à avoir bon niveau de sécurité, malgré une concurence massive.
Ou, si on est prêt à se casser la tête pour démontrer l'absence de tout overflow dans un programme concurent (bonne chance), faire du multithread masssif. Avoir des variables read-only protégées par mprotect peut aider un peu dans ce cas.
4. Enfin quand la fiabilité/sécurité est peu importante, mais la consommation CPU grosse (streams vidéos, jeux locaux ou en réseau...) alors faire du multithread sans démonstration, donc obligatoirement buggé vu la complexité pour gérer des threads.