Discussion :

[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.

[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.

[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.

[Mac LAK]

Quant faut il utilisé un semaphore, un mutex ?

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

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.

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...

[Ubiquité]

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.

[ikuzar]

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.

[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

[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.

[Mac LAK]

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.

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.

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.