semaphore ou mutex

Version imprimable

15/08/2009, 19h11
ikuzar

Bonjour,
Quant faut il utilisé un semaphore, un mutex ?
Corrigez moi si j'ai tort :
+ mutex : pour synchroniser 2 threads ( ou plusieurs ? ) d'un meme processus
+ semaphore peut jouer le role d'un mutex, de plus :
- il permet de synchroniser plusieurs threads d'un meme processus ou appartenant à
des processus différents
Si comme cela que j'ai compris le concept de mutex/semaphore.

Question suppémentaire :
Si par ex, trois threads doivent se synchroniser pour accéder à une seule ressource, dans ce cas il faut utiliser un sémaphore non ? puisque il y a plus de 2 threads ...
Merci d'avance pour vos réponses.
15/08/2009, 19h44
SofEvans

D'apres mes souvenir, un semaphore permet de proteger l'accées a une ressource critique, une ressource critique etant quelque chose (fichier, variable ... ) pouvant etre modifier par plusieurs thread.

Donc si trois (ou un quelconque nombre) thread vienne a modifier ta ressource, il faut effectivement un seul semaphore.
Par contre, si la ressource est en read-only, pas besoins de semaphore.
15/08/2009, 20h47
Ubiquité

A mon avis il te manque la théorie autour des semaphores. Tu devrais peut-être reprendre ton cours depuis le début :?.

Un mutex ne sert pas à synchroniser mais à empècher à plus d'un thread (ou processus peu importe) d'accéder en même temps à une même ressource.
Un semaphore peut servir à plus de choses, protéger une ressource mais aussi synchroniser.
16/08/2009, 04h58
Mac LAK

Citation:

Envoyé par ikuzar

Quant faut il utilisé un semaphore, un mutex ?

Quand tu as des problèmes d'accès concurrents à des ressources critiques.

Citation:

Envoyé par ikuzar

Corrigez moi si j'ai tort :

Tu as tort... ;)
En fait, un mutex est un sémaphore à un seul jeton. Souvent, sa gestion est plus simple (BEAUCOUP plus simple) qu'un sémaphore "général", c'est pour cette raison qu'il est distingué du sémaphore "général".

En gros, en raisonnant en jetons : un sémaphore à N jetons permet à N unités d'exécution d'accéder à une ressource donnée simultanément. Si N vaut un, alors une seule unité d'exécution à la fois peut accéder à la ressource en question (ce que l'on appelle une section critique).

Côté synchronisation, elle est faite tout simplement en prenant un sémaphore à N jetons, pour N unités d'exécutions qui prennent un jeton au début de leur traitement, et le relâchent à la fin.
Dans l'unité d'exécution principale, on sait que les unités ont fini leur travail lorsque tous les jetons ont été rendus. Ceci est en général fait en attendant N fois le signalement de libération d'un jeton.

Citation:

Envoyé par ikuzar

Si par ex, trois threads doivent se synchroniser pour accéder à une seule ressource, dans ce cas il faut utiliser un sémaphore non ? puisque il y a plus de 2 threads ...

Non, c'est un mutex, car un seul thread à la fois doit pouvoir accéder à la ressource en question.
Un sémaphore ne serait utilisé que si la ressource tolérait, par exemple, deux (ou plus) threads simultanément...
16/08/2009, 11h57
Ubiquité

Citation:

Envoyé par Mac LAK

En fait, un mutex est un sémaphore à un seul jeton.

Et seul le thread qui a fait P peut faire V. Alors que sur un semaphore, un thread peu très bien ajouter x jetons alors qu'il n'en a pris aucuns.
16/08/2009, 19h02
ikuzar

Citation:

Mac LAK >
En gros, en raisonnant en jetons : un sémaphore à N jetons permet à N unités d'exécution d'accéder à une ressource donnée simultanément

Ce n'est pas plutot : ... accéder à DES ressources données simultanément. ?
C'est le "UNE ressource donnée" et le "simultanément" qui me troublent ... comment UNE ressource peut être accédée SIMULTANÉMENT par plusieurs unités d'exécution.
16/08/2009, 19h20
SofEvans

Je ne sais pas si mon exemple va etre correct :

Imagine plusieurs thread : par definition, l'OS va donner pour chacun d'eux une periode afin qu'il puisse s'executer.

Il y a donc 3 thread. Ces trois thread vont agire sur un fichier.
Le thread 1 s'execute, il ouvre le fichier et commence a lire le fichier (il y accede donc). L'OS decide alors que c'est au thread 2. Le thread 2 effectue la meme operation que le thread 1, c'est a dire qu'il va ouvrir le fichier afin d'y lire.
Viens le tour du thread 3, les deux thread precedent ayant acceder au fichier pour le lire et n'ayant pas fini. Maintenant, le thread 3 accede lui aussi au fichier mais cette fois ci pour le modifier completement. Lorsque le thread 1 va reprendre la lecture, le contenue aura été modifier sans qu'il le sache.

Le but du mutex est d'empecher ceci.

Les semaphore sont un peu plus performant. Imagine que tu ai 20 thread, dont 19 ne font que lire le fichier, aucune modification n'y est faite et il y a 1 thread qui vient modifier le fichier.
Avec l'utilisation du mutex, tu vas devoir attendre que chaque thread finisse, un seul thread pouvant acceder au fichier. Avec les semaphore, tu va pouvoir dire quelque chose du style "tout ceux qui ne font que lire, vous pouvez y acceder en meme temps".

J'espere ne pas t'avoir embrouiller, va voir l'exemple des lecteur/redacteur, je crois que c'est un exemple repandue pour l'initiation au semaphore.

Si je me suis trompé, corrigez-moi
16/08/2009, 19h53
Ubiquité

Si tu veux comprendre comment fonctionne les mutex et les semaphores, oublis les mutex et concentre toi sur les semaphores. Une fois que tu les maitrisera, les mutex te paraitront simplissimes. En fait tout les IPC te paraîtront simplissimes une fois que tu auras passé les semaphores.
16/08/2009, 22h46
Mac LAK

Citation:

Envoyé par Ubiquité

Et seul le thread qui a fait P peut faire V. Alors que sur un semaphore, un thread peu très bien ajouter x jetons alors qu'il n'en a pris aucuns.

C'est exact. Toutefois, dans un sémaphore strict, on ne peut pas ajouter plus de jetons que le maximum défini à la création du sémaphore.

Citation:

Envoyé par ikuzar

Ce n'est pas plutot : ... accéder à DES ressources données simultanément. ?
C'est le "UNE ressource donnée" et le "simultanément" qui me troublent ... comment UNE ressource peut être accédée SIMULTANÉMENT par plusieurs unités d'exécution.

Non : une ressource = un élément de synchronisation. Si tu as 20 ressources, tu y mettras 20 éléments de synchronistation, cela n'est pas négociable.

Par contre, par "ressource", j'entends "ressource critique", et non pas "sous-ressources requérant de toutes façons l'accès exclusif à une ressource maître". Si par exemple tu accèdes à des lignes d'entrées/sorties sur une carte, un mutex sur les lignes individuelles ne sert à rien car c'est la carte d'E/S elle-même qu'il faut protéger, et non pas ses sous-éléments.

Citation:

Envoyé par SofEvans

Avec les semaphore, tu va pouvoir dire quelque chose du style "tout ceux qui ne font que lire, vous pouvez y acceder en meme temps".

Pas tout à fait. Là, tu décris un mutex lecteurs/rédacteur, qui est en général implémenté (de façon interne, c'est totalement transparent pour l'utilisateur) via deux sémaphores particuliers et utilisés conjointement, avec parfois un mutex en plus.
Mais ce n'est pas possible avec un seul sémaphore, par contre.