Discussion :

[ram-0000]

J'ai trouvé ce code qui semble le permettre

C'est une usine à gaz ce code, au lieu de créer une section citique utilisée par les readers et les writers, on créé 3 événements.

Effectivement tous les readers peuvent lire simultanément. Ceci dit, le temps de lock/unlock d'une section critique est très très rapide (beaucoup plus qu'un Event et son appel WaitForSingleEvent).

[gbdivers]

Ca peut quand même être intéressant si tu as beaucoup d'accès en lecture en même temps et que les temps de lectures sont longs (on parle de threads ici, mais l'idée pourrait être transposés aux bases de données par exemple)
Par contre, je trouve aussi que ça fait un peu usine à gaz, j'aurais plus vu une approche similaire à un shared_ptr (qui nous fait un proposal pour un shared_lock ? ) Sinon, peut être avec les condition_variable ou les adopt_lock ?

[Emmanuel Deloget]

Juste histoire de rajouter mon petit grain de sel : il y a deux aspects importants dans un accès atomique à une donnée. Le premier est bien évidemment l'accès lui-même, qui doit être non interruptible par un autre accès à la même donnée. Le second point est plus obscur, et concerne directement le fonctionnement des microprocesseurs actuels : en pus d'accéder à une variable de manière atomique, il faut aussi faire en sorte que cette variable soit récupérée/partagée depuis/vers les autres threads.

Je vous encourage à lire (shameless plug, désolé) mon billet sur le sujet. je vous le concède, c'est abscons.

Ceci dit, on en déduit quelques petites choses intéressantes :

Bonjour,

Seulement si l'opération effectuée n'est pas atomique (ie se faisant en une seule opération).

On peut par exemple regarder la valeur d'une variable booléenne/d'un char/short/int ou lui affecter une valeur sans nécessairement passer par une section critique.

Si si, c'est obligatoire - pour au moins une bonne raison : la section critique va implémenter les barrières mémoires nécessaires à ce que la variable soit vue correctement. Si la variable est dans le cache processeur en version non modifiée, un code sans barrière mémoire va récupérer la version dans le cache, et non pas la version mise à jour dans la mémoire centrale. A noter que le mot-clef volatile ne changera rien à cela : il n'ajoute pas de barrière mémoire à lui seul.

Du coup, et contrairement à la croyance générale, la lecture d'un int, bool, char, float... n'est PAS atomique (puisqu'une mise à jour du cache peut avoir lieu).

La réponse vaut aussi pour les commentaires suivants :

Mieux vaut faire : (passed_struct->entier)++; l'incrémentation pouvant être atomique selon le type de entier.

(l'incrémentation n'est pas atomique : il y a lecture + incrémentation + écriture de la donnée ; le processeur ne sait pas incrémenter la valeur d'une zone mémoire directement, même si l'instruction assembleur le fait croire ; de plus, inc n'ajoute pas de barrière mémoire, donc la lecture pourrait ne pas se baser sur la bonne valeur, et l'écriture pourrait ne pas être visible par les autres threads ; une barrière mémoire d'acquisition et une de libération sont nécessaires).

Permettez-moi de n'incruster...

La section critique n'est utile qu'en écriture, pas en lecture, n'est-ce pas ?
Tous les threads peuvent accéder simultanément en lecture à une resource.
Mais alors comment:
-lorsqu'un thread veut accéder en écriture, bloquer tous les autres threads ?
-lorsqu'un thread veut accéder en lecture, ne bloquer que ceux qui veulent accéder en écriture ?
merci.

(Idem, une section critique n'est pas qu'un accès atomique à une variable)

Tant qu'il n'y a pas de demande d'écriture, comment ne pas bloquer les lectures afin qu'elles puissent avoir lieu simultanément, tout en les bloquant lorsqu'il y aura une écriture ? (blocage seulement dans ce cas précis)

Une technique possible est d'utiliser un mécanisme qui s'appelle RCU - Read/Copy/Update. En gros, histoire de simplifier l'explication :

* un code qui a besoin de lire la donnée demander au système RCU son déréférencement. Dès qu'il a fini, il prévient le système RCU.
* une code qui a besoin d'écrire la donnée prévient le système RCU, qui lui donne une copie de la donnée. Le code écrit la donnée, et la libère. Le système met la donnée dans un cache.
* toute demander ultérieur de la donnée permet de récupérer la nouvelle valeur.
* dès que toutes les demandes de lecture antérieures au changement sont terminée, le système RCU fait un swap atomique (avec les barrières mémoire qui vont bien) de la donnée.

Il existe une implémentation userspace de RCU sur Linux (cf. http://git.lttng.org/?p=userspace-rcu.git). Il semblerait qu'elle ait été testée avec cygwin (donc sous Windows) mais je n'ai pas le statut de ce test. Si la compilation se passe bien, on devrait pouvoir obtenir une DLL qui serait alors utilisable par d'autres compilateurs (par exemple Visual C++). Ceci dit, la DLL en question se traînera une dépendance sur les DLL cygwin.

[camboui]

Est-ce que vous pourriez, vous ainsi que ceux qui trouvent le code que j'ai posté "usine à gaz" (pour une poignée de lignes de code...), proposer un code alternatif et générique à ce code ?
Perso, la protection d'une donnée atomique est un cas d'école. En général la ressource partagée à protéger est "lourde" (eg données sur disque).