1. Performances: consommation de CPU et de mémoire supplémentaire. Mutex obligatoire.
2. Sécurité/fiabilité: libérer une zone utilisée par les autres threads peut produire des bugs silencieux.
1) C'est clair que si on appelle un mutex système on a une consomation de CPU et de mémoire supplémentaire, mais alors on est protégé de façon complète. Ceci étant ca ne consomme pas plus qu'un mutex sur SHM (exactement la même chose en fait)
2) Là c'ets un problème de programation. Déjà si on est passé par un mutex système il faut vraiment le faire exprès pour le faire sauter par un autre thread. Par contre si on est passé par un simple lock interne on est obligé de suivre attentivement le thread lockeur sois-même, masi d'una utre coté si on passe par un lock interne on a pas d'overhead mémoire ou CPU.
Beaucoup d'applications perfermantes sont obligées de gérer elle-meme leur allocations ou d'utilisent une bibliothèque d'allocation plus rapide (quitte à consommer un peu + de mémoire).
Tout à fait, mais aucune sous allocation multiprocess ne peut aller aussi vite qu'une sous allocation multi-threads. La mémoire est beaucoup plus facile à réutiliser en mode thread qu'en mode process. Un modèle d'allocation par doublage par exemple prend deux lignes en threads mais necessite du code pointu en shm.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
2. Sécurité/fiabilité: libérer une zone utilisée par les autres threads peut produire des bugs silencieux.
1) C'est clair que si on appelle un mutex système on a une consomation de CPU et de mémoire supplémentaire, mais alors on est protégé de façon complète. Ceci étant ca ne consomme pas plus qu'un mutex sur SHM (exactement la même chose en fait)
2) Là c'ets un problème de programation. Déjà si on est passé par un mutex système il faut vraiment le faire exprès pour le faire sauter par un autre thread. Par contre si on est passé par un simple lock interne on est obligé de suivre attentivement le thread lockeur sois-même, masi d'una utre coté si on passe par un lock interne on a pas d'overhead mémoire ou CPU.
Beaucoup d'applications perfermantes sont obligées de gérer elle-meme leur allocations ou d'utilisent une bibliothèque d'allocation plus rapide (quitte à consommer un peu + de mémoire).
Tout à fait, mais aucune sous allocation multiprocess ne peut aller aussi vite qu'une sous allocation multi-threads. La mémoire est beaucoup plus facile à réutiliser en mode thread qu'en mode process. Un modèle d'allocation par doublage par exemple prend deux lignes en threads mais necessite du code pointu en shm.