Discussion :

[cosmoff]

Bonjour à tous,

voila si j'ai 2 thread qui ont besoin d'une meme ressource. Le premier thread exécute l'instruction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mutex.lock();

il va donc lire un attribut de l'objet de la class std::mutex, et si l'attribut n'est pas verrouillé par le second thread, alors le premier thread va mettre un attribut à True en modifiant dans la RAM la valeur d'un attribut pour verrouiller le mutex. Si le second thread tombe sur l'instruction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mutex.lock();

le second thread devra attendre (car instruction bloquante) que le premier thread déverrouille le mutex pour pouvoir acceder à la ressource. C'est le comportement normale que l'on souhaite avoir.

Mais est ce possible qu'on arrive dans le cas ou le premier thread voit que le mutex n'est pas verrouillé, le verrouille, mais qu'en parallèle le second thread était en train d'écrire dans la RAM pour mettre l'attribut à verrouiller, et on serait dans le cas ou les 2 threads on accès à la meme ressource mémoire ?

Merci d'avance pour vos réponses

[koala01]

Salut,
Non, si un mutex est a subit une instruction "lock", toute fonction qui essayerait d'utiliser lock sur le mutex se verrait "block".

Et la première arrivée est la première servie :en interne, la vérification est définie pour être "atomique" : il n'y a absolument pas moyen que "quelque chose" vienne "poser la question" alors que l'on est déjà occupé à y répondre pour "quelque chose d'autre".

[dalfab]

Tu poses en effet une bonne question. Si un mutex n'était fait que de simples accès mémoire "je teste puis j'écris", ça ne pourrait pas fonctionner.
On a besoin dans ce cas d'utiliser une capacité spéciale du processeur. On a besoin par exemple :
- instruction "test and set". C'est une instruction assembleur garantie atomique qui va tester puis écrire en garantissant qu'entre ces étapes qu'aucun processeur, ni aucune interruption n'agira entre les deux.
- "swap atomique". Une adresse mémoire est lue et remplacée de manière atomique.
- d'autres accès garantis atomiques comme le "read then write".
Pour la plupart des processeurs Intel, il existe une ribambelle de moyens. Pour les processeurs RISC il n'y a souvent qu'une unique instruction insécable.

Pour se protéger des interruptions concurrentes en environnement multiprocesseur, c'est un peu plus complexe on doit utiliser un mécanisme actif appelé "spin lock" (si une interruption en a bloquée une autre, quand elle se termine elle peut devoir réveiller un autre processeur.)

[cosmoff]

merci beaucoup dalfab pour ta réponse tres complete !

j'ai regardé un peu sur le net pour l'instruction Test and set en assembleur, mais pas moyen de trouver la commande qui réalise cela. On est d'accord que l'instruction test and set est réalisé par une commande en assembleur comme add, jump, cmp, move ...

[dalfab]

De mémoire, le test and set je l'ai utilisé par les processeurs d'origine motorola, il doit être dans le processeur PowerPC.
Le swap je l'ai utilisé sur processeur ARM.

Je viens de voir l'article wikipedia https://fr.wikipedia.org/wiki/Test-and-set qui dit une belle connerie (on ne peut l'écrire comme ça en C)

[cosmoff]

ok merci pour les infos

et oui effectivement j'avais vu tout a l'heure l'exemple de wiki qui est archi faux

[chrtophe]

De mémoire, le test and set je l'ai utilisé par les processeurs d'origine motorola, il doit être dans le processeur PowerPC.
Le swap je l'ai utilisé sur processeur ARM.

Sur x86, en assembleur, il y a l'instruction BTS pouvant être préfixée par LOCK pour être atomique dans un environnement multi-processeurs.

[ekieki]

Sur powerpc, il y a la notion de réservation.

Exemple de code pour incrémenter un entier de façon atomique. Quand on fait le lwarx, ça charge un entier en
notant dans un registre (unique au processeur) l'adresse du truc dont on veut se réserver l'accès.

L'écriture conditionnelle stwcx vérifie que l'entier qu'on veut modifier est bien celui qui est réservé. Sinon c'est que quelqu'un nous a chipé la réservation, alors on recommence.
La probabilité étant très faible, c'est un moyen peu pénalisant.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
retry:
  lwarx  r4, 0, r3 // Read integer from RAM into r4, placing reservation.
  addi   r4, r4, 1 // Add 1 to r4.
  stwcx. r4, 0, r3 // Attempt to store incremented value back to RAM.
  bne-   retry     // If the store failed (unlikely), retry.

voir https://www.ibm.com/developerworks/l...tom/index.html

[Médinoc]

Je viens de voir l'article wikipedia https://fr.wikipedia.org/wiki/Test-and-set qui dit une belle connerie (on ne peut l'écrire comme ça en C)

En effet, ça donne un beau contraste avec la page anglophone, où le même code contient ce commentaire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
    // -- Start of atomic segment --
    // This should be interpreted as pseudocode for illustrative purposes only.
    // Traditional compilation of this code will not guarantee atomicity, the
    // use of shared memory (i.e., non-cached values), protection from compiler
    // optimizations, or other required properties.