Synchronisation accès mémoire en mémoire partagée

Bonjour à tous,

J'ai crée une mémoire partagée entre deux applications. La variable partagée est une structure :

Code:

---

1 2 3 4 5 6 7

typedef struct { unsigned char img[NB_ELEMENTS]; //NB_ELEMENTS est une macro int statusAPP1ToAPP2, statusAPP2ToAPP1;   } dataShm;

---

Au lieu d'utiliser les sémaphores, j'ai pensé à une autre méthode qui consiste à utiliser deux variables (statusAPP1ToAPP2, statusAPP2ToAPP1) qui notifie l'autre application que les données peuvent être lu/écrites.

Dans la suite je vais désigner mes deux applications par APP1 et APP2.
Ainsi, à un endroit du code de APP2 j'ai les lignes suivantes:

Code:

---

1 2 3 4 5 6 7 8 9 10

.... // Initialisation et allocation de la mémoire partagée // On attend que des données arrivent while(1){   while(data->statusAPP1ToAPP2 != READY); // Tant que APP1 n'a pas mis à jour cette variable on reste coincé dans la boucle   // La variable data->statusAPP1ToAPP2 a été mise à jour: les données sont prêtes à être traitées... ..... }

---

Dès que mon application 1 (APP1) a mis la variable

Code:

---

data->statusAPP1ToAPP2

---

à READY APP2 doit pouvoir traiter les données. Or, APP2 ne sort jamais de la deuxième boucle... En revanche en mettant une instruction usleep(1) juste avant la boucle

Code:

---

while(data->statusAPP1ToAPP2 != READY);

---

, le programme arrive à voir que la variable a été modifié à READY et commence à traiter les données. Ce choix de synchronisation est très critiquable cependant j'aimerais bien comprendre ce qui se passe.

Quelqu'un a-t-il une idée de la raison pour laquelle la variable n'est pas mise à jour sans l'instruction usleep... ? J'ai l'impression que la condition data->statusAPP1ToAPP2 != READY n'est pas évalué ... Des suggestions ?

À moins d'être prévenu, le compilo suppose qu'une variable ne change pas tant que ton programme ne la change pas lui-même. Et il fait ses optimisations en conséquence.

Comment sont créées tes 2 applications ?
fork ? pthread ?... (je suppose pthread)

C'est une mauvaise idée de ne pas utiliser de sémaphore ou de lock, car ton while fera de l'attente active (et consommera 100% de ton CPU).
Les sémaphores et locks agissent comme des interruptions : dès que la condition est fausse, le processus est délaissé, tant que la condition n'est pas devenue vraie (ce qui est plus efficace déjà :P).

Es-tu sûr en effet que APP2 arrive à atteindre ton instruction ?
Pas de dead lock possibles à tout hasard ?

EDIT : Je pense que Médinoc a ta réponse sur le "pourquoi" ! ;)

L'idée était de créer une interface simple pour faire communiquer les deux applications (en utilisant la librairie shm) sans utiliser les sémaphores, mutex etc... J'avais pensé à l'explication de Médinoc mais je n'étais pas sûr si le compilateur pouvait faire de telles optimisations.

Je vous remercie de votre aide.

Si tu veux faire ce genre de choses, il te faudra au moins un test-and-set atomique pour tout ce qui concerne l'exclusion mutuelle (sous gcc sur x86, ce doit être possible avec un peu d'assembleur inline, si tu n'as pas déjà les fonctions qu'il faut).

PS: Une attente active n'est pas "légère". Ce n'est pas pour rien qu'on utilise les attentes passives fournies par l'OS...

Si jamais ça peut en intéresser d'autres, il suffit de mettre le mot clé

Code:

---

volatile int a;

---

devant le type d'une variable afin que le compilateur n'apporte aucune optimisations sur celle-ci --> elle sera donc évaluée à chaque fois qu'on l'invoque et mon problème aurait été résolu. Cependant, l'idée d'utiliser des mécanismes reposant sur les sémaphores/mutex est meilleure en terme de conso CPU.

Citation:

---

Envoyé par Médinoc

À moins d'être prévenu, le compilo suppose qu'une variable ne change pas tant que ton programme ne la change pas lui-même. Et il fait ses optimisations en conséquence.

---

On peut éviter les optimisations d'une variable en utilisant volatile si je ne m'abuse.

8-)

EDIT: Désolé j'ai manqué ton dernier message degodskitchen :cry: