Si tes estimations sont exactes, c'est en effet un scheduler interne performant.
Le plus long est de poser des masques sur les threads pour els signaux. Mais après le role de ce scheduler est très réduit.
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.
Ou quand on veut une bonne maitrise de la synchro, ou quand on veut un déroulement "dans l'ordre" de certaines fonctions (en temps réel par exemple), ou quand on veut prioritiser dynamiquement un thread par rapport à l'autre sans nicer tout le processus ou quand veut effectuer un maximum de changement entre deux threads dans le time-slice etc.
En attendant que mon reve se réalise, avoir des threads avec des variables privées protégées par sigsegv,
Dans les threads c'est vrai qu'il n'y a pas de variables vraiment pivée, mais si tu protèges une zone mémoire autant que tu le peux, le thread qui passe au travers ne peut pas vraiment prétendre ne pas l'avoir fait exprès (on n'outrepasse pas un writelock par débordement de tableau).
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.
Tout à fait, les meccanismes de callback peuvent aussi aider grandement.
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.
La séparation des privilèges ne nécessite pas forcément la séparation des process. Il existe un autre système d'IPC qui s'apelle les signaux. C'était le système de référence dans Unix devant les sockets et les pipes. On peut parfaitement définir des masques d'interceptions qui assurent que tel signal sera toujours traité par tel thread.
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.
Gérer des threads peut être très simple sur des taches concurentes parallèles, ne serait-ce que parceque je peux régler l'ordre de déroulement de mes threads sans faire de tests via le scheduler PThread. Tache ardue, si ce n'est impossible avec le scheduler standard.
Les threads permettent également de découper le traitement en petits traitements simples de façon très simple, alors que faire la même chose en SHM demande souvent de créer des protocoles de dialogues inter-processus complexes.
[^] # Re: scheduler intra-processus, voir plus haut, sécurité/rapidité
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Le plus long est de poser des masques sur les threads pour els signaux. Mais après le role de ce scheduler est très réduit.
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.
Ou quand on veut une bonne maitrise de la synchro, ou quand on veut un déroulement "dans l'ordre" de certaines fonctions (en temps réel par exemple), ou quand on veut prioritiser dynamiquement un thread par rapport à l'autre sans nicer tout le processus ou quand veut effectuer un maximum de changement entre deux threads dans le time-slice etc.
En attendant que mon reve se réalise, avoir des threads avec des variables privées protégées par sigsegv,
Dans les threads c'est vrai qu'il n'y a pas de variables vraiment pivée, mais si tu protèges une zone mémoire autant que tu le peux, le thread qui passe au travers ne peut pas vraiment prétendre ne pas l'avoir fait exprès (on n'outrepasse pas un writelock par débordement de tableau).
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.
Tout à fait, les meccanismes de callback peuvent aussi aider grandement.
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.
La séparation des privilèges ne nécessite pas forcément la séparation des process. Il existe un autre système d'IPC qui s'apelle les signaux. C'était le système de référence dans Unix devant les sockets et les pipes. On peut parfaitement définir des masques d'interceptions qui assurent que tel signal sera toujours traité par tel thread.
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.
Gérer des threads peut être très simple sur des taches concurentes parallèles, ne serait-ce que parceque je peux régler l'ordre de déroulement de mes threads sans faire de tests via le scheduler PThread. Tache ardue, si ce n'est impossible avec le scheduler standard.
Les threads permettent également de découper le traitement en petits traitements simples de façon très simple, alors que faire la même chose en SHM demande souvent de créer des protocoles de dialogues inter-processus complexes.