Discussion :

[archimondain]

Bonjour
J'ai un programme avec 2 threads sur une architecture classique 32 bits , et j'ai des variables de type simple (int) à protéger à la fois d'un accès concurrent écriture/écriture, et d'un accès concurrent lecture/écriture.

Le mot clef volatile me protège contre un accès écriture/écriture.
Mais je ne sais pas si il protège aussi un accès concurrent lecture/écriture.
Quelqu'un aurait-il la réponse ? (un thread peut-il lire la valeur d'une variable au même moment ou un autre est en train de la modifier, et lire alors une valeur érronée, ou lira-t-il forcément soit la valeur juste avant la modification, soit la valeur juste après ?)

Merci d'avance

[ram-0000]

Le mot clé volatile indique uniquement au compilateur à ne pas faire de simplification sur la lecture. Il indique que cette variable peut être modifiée de manière externe.

Exemple avec le code suivant :

Code :

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

1
2
3
4
int val = 1;
while(val == 1)
{
}

Le compilateur pourrait très bien simplifier en ignorant la variable val et en écrivant quelque chose comme cela (puisque val n'est pas utilisé) :

Code :

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

1
2
3
for(;;)
{
}

Le fait de mettre le mot clé "volatile" indique au compilateur qu'il ne doit pas faire de simplifications.

Le mot clé volatile trouve son utilité dans le cas d'une variable du programme dont la valeur peut être modifiée par une interruption (donc hors contexte du programme).

[archimondain]

Merci,
Mais ça ne répond pas à ma question

En fait je devrais sans doute reformuler :

Sur une architecture classique, 32 bits, avec 2 processeurs (précision qui a son importance)
- un premier thread va effectuer une opération d'assembleur pour lire un emplacement mémoire de 4 octets.
- un deuxième thread va effectuer une opération d'assembleur pour écrire dans ce même emplacement mémoire.

la valeur lue par le premier thread pourra-t-elle être incohérente, ou sera-t-elle forcément soit une valeur présente avant l'écriture du deuxième thread, soit une valeur présente après l'écriture du deuxième thread ?

Merci d'avance

[ram-0000]

Mais ça ne répond pas à ma question

Alors le titre du post n'est pas adéquat

Dans ton cas, il faudra passer par des opérations de lectures/écritures atomiques.

Je ne connais pas ton OS cible mais sous Windows, regarde du côté des Interlocked variable access

Lu ici : Interlocked Variable Access

Simple reads and writes to properly-aligned 32-bit variables are atomic operations. In other words, you will not end up with only one portion of the variable updated; all bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation.

Simple reads and writes to properly aligned 64-bit variables are atomic on 64-bit Windows. Reads and writes to 64-bit values are not guaranteed to be atomic on 32-bit Windows. Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform.

[3DArchi]

Comme le dit ram-0000, volatile ne garantie rien en terme de multithread. Si tu as un risque de race condition, il faut protéger. volatile dit juste que la variable peut changer hors du contexte de son utilisation immédiate (les fameuses interruptions) et donc éviter certaines optimisations qui auraient pu avoir lieu par ailleurs.

[archimondain]

Merci pour vos réponses
Effectivement j'aurai du poster ailleurs.
Ce que je comprend c'est que volatile me garantis que mes opérations lecture/ecriture s'effectuerons bien dans le même emplacement mémoire (et pas dans un registre ou autre optimisation du compilo).

J'ai fait quelques tests, et sur une architecture 32 bits avec plusieurs processeurs, les opérations de lecture/écriture sur 4 octets sont bien atomiques, et il ne semble pas y avoir de risque qu'un thread lise les 4 octets alors que l'autre a modifié les deux premiers sans modifier les deux derniers.

Quand il n'y a que des accès a des variables de type simple sur 4 octets à protéger (entier, float, pointeur), il semble donc superflue d'utiliser des mutex, le mot-clef volatile suffit.