je vois souvent ces termes apparaitre, mais je sais pas ce que c'est ni à quoi ça sert...
 
quelqu'un pour m'expliquer
 

objet pour la synchro de threads
 
un mutex a deux etats : ouvert et ferme.
Si jamais tu essaye de le fermer alors qu'il l'est deja alors tu est automatiquement mis en attente jusqu'a ce qu'il soit ouvert (et que donc tu puisse le fermer)

et semaphore   c'est presque  pareille excepter que c'est un compteur/decompteur qui bloque ce lui qui veut le descendre sous zero ah aussi ce n'est pas que pour les threads mais pour le multi-process ,multi-thread

J'ajouterai (en reformulant) que c'est utilise pour l'utilisation de ressources critiques.
 
Dans la litterature, tu as pas mal d'exemple comme les philosophes mangeur de spaghetti. Le plus classique est celui du producteur consommatteur.
 
Tu as un client qui demande a consommer un produit, qu'il va chercher dans une reserve. La contrainte est qu'il ne peut aller chercher un produit que si il en reste. Si la reserve est vide, il est bloque, jusqua'a ce que le producteur fournissent une unite.
 
Bon voila, c'est resume ... bonne recherche

ou pour l'acces a des ressources partagées (lecture/ecriture dans une zone memoire partagée, un peripherique, ...)
 

 
2 petites choses : un mutex est un sémaphore booleen.
 
C'est le regretté Dijkstra qui a introduit ce concept et le vocabulaire.

on peut aussi dire qu'un MUTEX, c'est un semaphore avec un jeton/ticket...

On peut dire qu'il aura laisse quelque chose derriere lui !  
 
Dijkstra, si tu nous lis :    

 
il ne laisse pas que ça, pour en rassurer certains : "Dijkstra était littéralement malade à l'idée de programmer en C++"
 
Je trouve plus la référence, c'est con ! (surtout douteux en fait)

d'ailleurs ca veut dire quoi mutex?
 
ca veut simplement dire "mutuellement exclusif":
une fois acquis il ne peut être acquis par
quelqu'un d'autre ce qui permet
de définir des sections critiques  
dans un code (section où l'on ne peut
s'engager que un à la fois lorsque l'autre est sorti).
 
Ensuite tu as les signaux (plusieurs threads
sont en attente d'un evenement dans un autre thread),  
les objets read/write (tu as un seul ticket write qui  
ne peut être acquis que lorsqu'il n'y a plus
de tickets read en circulation. Et les tickets read
ne peuvent être distribué que tant que personne
n'a acquis le ticket write.).
Tu as des strategies de priorite; si tu as plusieurs
threads qui sont en attente pour une ressource
dans quel ordre tu les reveilles ? En general
c'est une fifo (dans l'ordre d'arrivee comme chez le dentiste)
parfois il y a des ordres de priorité, on attend que la file de priorité se vide avant de servir la file des communs (comme aux urgences). Evidemment il y a parfois risque d'affamement lorsqu'il y a trop de gens dans la file prioritaire et que les communs ne sont jamais servis (comme dans la réalité..).
 
Tu as des problemes liés à la distribution des tickets: si chacun prend les tickets comme il le sent et qu'il a besoin de plusieurs tickets pour achever une tâche, alors il y a de fortes chances pour que la situation se bloque (ce qu'on appelle un deadlock ou obstruction).
 
Heureusement dans un programme d'ordinateur tu es le dieu tout
puissant et chaque ligne de code fait strictement ce que tu as demandé. Donc si la situation se bloque, il y a de fortes chances pour que ce soit de ta faute .
 
LeGreg

Dr Dobb's: You've mentioned Edsgar Dijkstra. What do you think of his work?
 
Knuth: His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.
 
http://home.hccnet.nl/h.vink/lead.htm
 

Bon ok, considerons le code ci dessous avec le mutex g_hMutex de creer. A ce que j'ai compris, dans le cas ou plusieurs threads s'executent, chacun s'execute a un instant precis d'une duree aleatoire.
Ainsi supposons que dans la boucle infini ci dessous, a un certain moment, ce thread est actif 1 seconde ; le thread s'execute, relache le jeton puis tout de suite reprend le jeton...comment les autres threads font pour avoir le jeton pile poil au moment au le thread le relache parce que si a ce moment ou le jeton est relache les autres threads ne s'execute pas, le thread qui a libere le jeton le reprend aussitot non ?
 
Une autre question : mes threads s'execute dans differents fichier. Pour que chacun puis acceder au Mutex, je suis oblige de passer par une variable globale ?   (puis de faire des extern)
 

Certains OS garantissent que les process en attente d'un mutex seront placés dans une FIFO (first in first out).
 
Donc si ton process relache ton jeton et qu'il le reclame tout de suite apres, s'il y a deja quelqu'un qui l'a demandé (et qui a été placé dans la file d'attente) il ne sera pas servi en premier.
 
Qu'est-ce que tu entends par "plusieurs fichiers" ??
Si c'est plusieurs modules Cpp (et pas différentes applications) alors je vois pas où est le problème.
 
LeGreg

Salut!
Moi aussi en consultant les infos de process XP, j'y ai trouvé ce terme mutex associé à un début de ligne "mutant". Etant profane, j'avais une petite inquiétude toute relative quand même.  
Et j'ai pris un très bon plaisir à vous lire, même si je n'ai compris que superficiellement l'explicatif, (jen suis à ma premiere lecture), je vais le relire .
je peux  poster un snap si ça vous dérange pas? peut etre ce sera plus facile à expliquer non?