Les systèmes modernes, dont Linux, utilisent le copy-on-write: les données ne sont dupliquées qui si elles sont modifiées.
Tu dupliques la page contenant la variable, c'est donc bien plus lent que les threads qui ne dupliquent rien (hormis le PC).
Tout programme doit vérifier lors de son lancement qu'il n'y a pas eu de crash précédemment, afin de remettre de l'ordre si besoin.
ce qu'il n'y pas besoin de faire avec les threads (en ce qui concernen la gestion du parallelisme).
Je ne dis pas que le choix des threads est tout le temps supérieur au choix du fork. ca dépend entièrement du projet. <mavie> Pour ma part, j'avais fait un projet il y a 6 ans pour l'INRA (Linux+OpenGL+Qt+IPC), ça traine encore sur ma page ouebe :-). Si c'était à refaire maintenant ce serait threads + sockets et pas fork + IPC. Les threads c'est beaucoup plus souple à mon sens (dans le cadre de ce projet en tout cas)...</mavie>
[^] # Re: vs POSIX shared memory
Posté par dcp . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 3.
Tu dupliques la page contenant la variable, c'est donc bien plus lent que les threads qui ne dupliquent rien (hormis le PC).
Tout programme doit vérifier lors de son lancement qu'il n'y a pas eu de crash précédemment, afin de remettre de l'ordre si besoin.
ce qu'il n'y pas besoin de faire avec les threads (en ce qui concernen la gestion du parallelisme).
Je ne dis pas que le choix des threads est tout le temps supérieur au choix du fork. ca dépend entièrement du projet. <mavie> Pour ma part, j'avais fait un projet il y a 6 ans pour l'INRA (Linux+OpenGL+Qt+IPC), ça traine encore sur ma page ouebe :-). Si c'était à refaire maintenant ce serait threads + sockets et pas fork + IPC. Les threads c'est beaucoup plus souple à mon sens (dans le cadre de ce projet en tout cas)...</mavie>
A toi la balle :-)