Atomicité lecture écriture 64 bits sur machine 32 bits

Bonjour à tous,

Je cherche à rendre atomique une opération de lecture/écriture sur un espace mémoire de 8 octets (64 bits) sur une machine à architecture 32bits.

je ne veux utiliser aucun lock (sémaphore, mutex etc) ni de solution de buffer tournant...

J'ai entendu parler d'une technique consistant à utiliser un cast de réel double sur la zone mémoire en question mais je n'arrive pas à le faire fonctionner :

la zone mémoire partagée par deux processus concurrents :

Code:

---

unsigned long long zone_64;

---

le code accédant à cette fonction en lecture :

Code:

---

1 2 3

char buffer[8];   *(double *)buffer = *(double *)&zone_64;

---

le code accédant à cette fonction en écriture :

Code:

---

1 2 3

char buffer[8]; //puis initialisation avec une valeur   *(double *)&zone_64 = *(double *)buffer;

---

Globalement le test que je fais consiste à créer deux processus :
un premier écrit 0x0000000000000000 puis 0xffffffffffffffff à l'infini avec le code d'écriture ci dessus et le deuxième lit avec le code de lecture ci dessus. Les programmes sont en priorité hautes et égales donc ont un accès concurrent sur la zone mémoire qui est une zone de mémoire partagée.

évidemment le résultat est que de temps en temps je lis 0x00000000ffffffff ou 0xffffffff00000000. (car l'opération d'écriture 64 bits sur architecture 32 bits n'est pas atomique).

j'ai essayé en plaçant des variables de type double intermédiaire, cela n'a pas marché ni en utilisant le mot clé volatile pour la variable en shm.

Si quelqu'un à déjà utilisé cette "méthode" du type double, je suis preneur !

merci.

Bonjour,

C'est-à-dire que, si ta machine est en 32 bits, rien ne te garantit que le C lui-même ne mette en place son propre système d'atomicité. En fait, il est même fort probable qu'il ne le fasse pas du tout puisque son problème serait le même que celui du programmeur, et qu'il n'y a pas de raisons pour que les infrastructures du C standard aillent d'elles-même causer avec le système d'exploitation.

Si la donnée à transférer est plus large que 32 bits et ne tient pas en entier dans un registre, alors la CRTlib devra mettre en place une boucle pour copier l'élément. Ce serait le cas avec une grande structure, par exemple. Et donc, cette boucle est interruptible par l'O.S. Ceci pour dire que même la manipulation d'un type natif censée être atomique vu du C est forcément décomposée lorsqu'elle est compilée en langage machine.

L'avantage de double, c'est que sa taille est normalisée (64 bits) et que la norme C garantit sa présence. Toutefois, j'utiliserais plutôt uint64_t si disponible, mais le problème resterait entier.

« volatile » était une bonne idée et ce serait bien dans ses attributions de mettre en place des mécanismes d'atomicité s'il c'était possible, mais le problème reste encore une fois le même. Son rôle est surtout de garantir que la donnée sera écrite en mémoire en temps voulu et pas conservée ad vitam dans un registre, inaccessible à un autre processus.


Si tu ne veux vraiment pas utiliser de sémaphore, mais que tu travailles sur x86, moi, je ferais un bout d'assembleur et j'essaierais de faire un LOCK MOVS. Avec un peu de chance, le CPU considérera MOVS comme étant une seule instruction. Sinon, ce serait étonnant qu'un compilateur C moderne ne propose pas de flags propriétaires servant à cela, quitte à baser cela sur un algo de Peterson, ou autre.

Merci pour ta réponse rapide.

Je vais continuer à fouiller un peu avec ces nouvelles infos (assembleur, flags de compil) mais je vais au final je pense utiliser un buffer tournant.

Je laisse le post ouvert au cas où quelqu'un aurait eu vent de cette 'méthode' du type double et qu'il veuille compléter !