> Chacun sait que les verrous sont une mauvaise façon de gérer la concurrence.
> Utilise plutôt du message passing.
Les deux ont leur intérêt. J'utilise lock (ou mutex), semaphore et signal (pthread_cond_wait pthread_cond_signal par exemple). Chaqu'un a son intérêt bien spécifique. Un signal ne peut remplacer un semaphore ou un lock, un lock ne peut remplacer un semphore ou un signal, etc, etc...
A moins de coder comme un porc avec des boucles de ce type :
while (!condition) {
sleep(1) ;
}
mutex/semaphore/signal sont indispensables.
Je suis sûr que "message passing" doit utiliser un lock ou un semaphore.
En passant, un mutex (ou section critique sous Windows) ça ne bouffe rien si le nombre de thread actif est inférieur ou égal au nombre de cpu/core. Il n'y a même pas un appel système de fait (donc on reste en userland). C'est redoutablement efficace.
[^] # Re: Multicoeur ?
Posté par IsNotGood . En réponse à la dépêche Intel libère TBB. Évalué à 2.
> Utilise plutôt du message passing.
Les deux ont leur intérêt. J'utilise lock (ou mutex), semaphore et signal (pthread_cond_wait pthread_cond_signal par exemple). Chaqu'un a son intérêt bien spécifique. Un signal ne peut remplacer un semaphore ou un lock, un lock ne peut remplacer un semphore ou un signal, etc, etc...
A moins de coder comme un porc avec des boucles de ce type :
while (!condition) {
sleep(1) ;
}
mutex/semaphore/signal sont indispensables.
Je suis sûr que "message passing" doit utiliser un lock ou un semaphore.
En passant, un mutex (ou section critique sous Windows) ça ne bouffe rien si le nombre de thread actif est inférieur ou égal au nombre de cpu/core. Il n'y a même pas un appel système de fait (donc on reste en userland). C'est redoutablement efficace.