(si j'ai bonne mémoire, les mutex sous Linux sont par défaut équivalent aux critical section de Windows).
Les mutex pthreads sont en tout cas extrêmement optimisé (bout écrit en asm itou itou itou).
Il y a aussi les futex (fast mutex) mais j'ai jamais touché.
Mais le faire montre une erreur de conception à mon sens.
Ben si tu n'as pas de sémaphore, tu fait comment ?
Libérer un mutex ou semaphore par une thread qui ne l'a pas acqui est généralement une erreur ou signe d'un conception "pas terrible".
Question de point de vue.
Tu as un pool d'utilisateur, par exemple 100.
Chaque utilisateur fait quelquechose.
Tu injecte un utilisateur tant que tu es inférieur à 100, et si tu atteint 100, tu attend qu'un parte.
Alors tu peux t'amuser à le faire avec des conditions et un compteur a coté mais bon, mais ca va etre assez lourd a gerer quand meme, et plus lent qu'avec un sémaphore. Et surtout ne vas pas régler le probleme que tu as soulevé : tu ne sera plus à 100 si un client "oublie" de lancer le signal quand il quitte la condition.
(par exemple le process qui a pris le mutex est mort suite à une erreur et donc ne va pas le libérer).
Enfin la ton mutex il est mort meme si il n'est pas appelable par un autre thread que l'appelant, donc tu es en deadlock.
A toi de vérifier tes critical section aussi.
tu voulais peut etre dire 'le process qui devait le libérer est mort' , et encore une fois tu es en section critique dans ce cas, c'est a TOI de coder pour qu'il n'y ait pas de deadlock. C'est vrai meme avec un mutex (cf plus haut)).
[^] # Re: Multicoeur ?
Posté par briaeros007 . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Les mutex pthreads sont en tout cas extrêmement optimisé (bout écrit en asm itou itou itou).
Il y a aussi les futex (fast mutex) mais j'ai jamais touché.
Mais le faire montre une erreur de conception à mon sens.
Ben si tu n'as pas de sémaphore, tu fait comment ?
Libérer un mutex ou semaphore par une thread qui ne l'a pas acqui est généralement une erreur ou signe d'un conception "pas terrible".
Question de point de vue.
Tu as un pool d'utilisateur, par exemple 100.
Chaque utilisateur fait quelquechose.
Tu injecte un utilisateur tant que tu es inférieur à 100, et si tu atteint 100, tu attend qu'un parte.
Alors tu peux t'amuser à le faire avec des conditions et un compteur a coté mais bon, mais ca va etre assez lourd a gerer quand meme, et plus lent qu'avec un sémaphore. Et surtout ne vas pas régler le probleme que tu as soulevé : tu ne sera plus à 100 si un client "oublie" de lancer le signal quand il quitte la condition.
(par exemple le process qui a pris le mutex est mort suite à une erreur et donc ne va pas le libérer).
Enfin la ton mutex il est mort meme si il n'est pas appelable par un autre thread que l'appelant, donc tu es en deadlock.
A toi de vérifier tes critical section aussi.
tu voulais peut etre dire 'le process qui devait le libérer est mort' , et encore une fois tu es en section critique dans ce cas, c'est a TOI de coder pour qu'il n'y ait pas de deadlock. C'est vrai meme avec un mutex (cf plus haut)).