Je te rappelle que l'article concerne la complexité du debuggage des threads.
Quedalle, debugger des threads concurrents c'est tout aussi complique debugger des processus concurrents, meme topo.
La question c'est laquelle des 2 architectures est la meilleure pour eviter des bugs et avoir des perfs decentes.
Tu n'es vraiment pas objectif car tu n'as pas un dit un mot sur l'enfer de ce debuggage comparé au débuggage des processus multiples. Cet enfer des threads est bel et bien du aux fait que les variables privées ne sont pas respectées et que les threads encouragent à faire des algorithmes multipliant les variables partagées inutiles, et donc ajoutant de nombreux besoins de synchronisation supplémentaires qui ne sont pas toujours suffisament pris en compte.
Rien du tout, la complexite du debuggage est la meme, mais bien evidemment tu ne le sais pas car tu n'as jamais essaye toi meme.
Le partage des donnees, que ce soit des threads ou processus avec shm c'est le meme topo.
Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.
Mais tu fais expres c'est pas possible...
Le seul fait de devoir faire des decalages pour les pointeurs si les segments ne peuvent etre mappes au meme endroit fait que la solution shm est totalement irrealiste, partant de la la question ne se pose meme pas, mais tu refuses de comprendre et t'obstines a croire une theorie que tu n'as jamais eprouvee plutot qu'ecouter qq'un qui a deja teste les 2 techniques.
On peut très facilement utiliser shm pour remplacer un pipe ou une socket entre 2 processus. Pas besoin de malloc pour faire cela. Ce faisant, on obtient des performances similaires aux threads tout en utilisant la technologie éprouvée des processus qui est à la base de la fiabilité des UNIX.
Ca c'est une conclusion qui prouve que tu n'as absolument rien compris au probleme.
Les shm oui c'est utile pour remplacer les pipe ou socket(dans certains cas), mais ca n'a rien a voir avec les threads et cela ne les remplace pas, pour la tres simple raison que les pipe et socket ca n'a jamais ete une alternative aux threads, c'est pour un usage different.
Je t'en prie, arretes de parler de maniere si affirmative d'une technologie que manifestement tu n'as jamais utilisee, ce que tu racontes est reellement effarant.
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Je te rappelle que l'article concerne la complexité du debuggage des threads.
Quedalle, debugger des threads concurrents c'est tout aussi complique debugger des processus concurrents, meme topo.
La question c'est laquelle des 2 architectures est la meilleure pour eviter des bugs et avoir des perfs decentes.
Tu n'es vraiment pas objectif car tu n'as pas un dit un mot sur l'enfer de ce debuggage comparé au débuggage des processus multiples. Cet enfer des threads est bel et bien du aux fait que les variables privées ne sont pas respectées et que les threads encouragent à faire des algorithmes multipliant les variables partagées inutiles, et donc ajoutant de nombreux besoins de synchronisation supplémentaires qui ne sont pas toujours suffisament pris en compte.
Rien du tout, la complexite du debuggage est la meme, mais bien evidemment tu ne le sais pas car tu n'as jamais essaye toi meme.
Le partage des donnees, que ce soit des threads ou processus avec shm c'est le meme topo.
Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.
Mais tu fais expres c'est pas possible...
Le seul fait de devoir faire des decalages pour les pointeurs si les segments ne peuvent etre mappes au meme endroit fait que la solution shm est totalement irrealiste, partant de la la question ne se pose meme pas, mais tu refuses de comprendre et t'obstines a croire une theorie que tu n'as jamais eprouvee plutot qu'ecouter qq'un qui a deja teste les 2 techniques.
On peut très facilement utiliser shm pour remplacer un pipe ou une socket entre 2 processus. Pas besoin de malloc pour faire cela. Ce faisant, on obtient des performances similaires aux threads tout en utilisant la technologie éprouvée des processus qui est à la base de la fiabilité des UNIX.
Ca c'est une conclusion qui prouve que tu n'as absolument rien compris au probleme.
Les shm oui c'est utile pour remplacer les pipe ou socket(dans certains cas), mais ca n'a rien a voir avec les threads et cela ne les remplace pas, pour la tres simple raison que les pipe et socket ca n'a jamais ete une alternative aux threads, c'est pour un usage different.
Je t'en prie, arretes de parler de maniere si affirmative d'une technologie que manifestement tu n'as jamais utilisee, ce que tu racontes est reellement effarant.