Discussion :

[Luke spywoker]

Salut les C, C++,

je voulais savoir si une variable déclarer comme _Atomic est une variable contenant une valeur sachant que une opération atomique soit réussis soit échoue complètement.

Ou si une variable déclarer comme _Atomic est plus une barrière mémorielle comme induit la glib ?

Car mon lecteur de musique mmp (Micro Music Player) bug dès fois oui dès fois non quand on enclenche le mode shuffle.

Sachant que le mode de lecture dépends de variables booléen ?

Merci pour vos réponses éclairées,

Luke Spywoker.

[ternel]

Si j'ai bien compris la documentation, _Atomic est une caractéristique de la variable (ou du pointé), comme const ou volatile.
J'en déduis qu'un _Atomic int contient un entier de la même manière qu'un int.

J'imagine que je n'ai pas compris ta question.

[sambia39]

Bonsoir

Si j'ai bien compris la documentation, _Atomic est une caractéristique de la variable (ou du pointé), comme const ou volatile.
J'en déduis qu'un _Atomic int contient un entier de la même manière qu'un int.

J'imagine que je n'ai pas compris ta question.

Non, pas tout à fait, c’est un équivalent exemple si l’on utilise _Atomic(int) x; on crée un spécificateur de formats en clair un nouveau type de variable atomique tant dit que si l’on fait ça _Atomic int x on crée juste une version atomique du nom de type int.

Salut les C, C++,

je voulais savoir si une variable déclarer comme _Atomic est une variable contenant une valeur sachant que une opération atomique soit réussis soit échoue complètement.

Ou si une variable déclarer comme _Atomic est plus une barrière mémorielle comme induit la glib ?

Car mon lecteur de musique mmp (Micro Music Player) bug dès fois oui dès fois non quand on enclenche le mode shuffle.

Sachant que le mode de lecture dépends de variables booléen ?

Merci pour vos réponses éclairées,

Luke Spywoker.

Oui, une variable atomique est une variable qui peut contenir une valeur, quant à la question à savoir si une variable atomique est comme une barrière mémorielle comme celle; définis par glib je dirais probablement "oui, mais cela dépend de l’opération", mais dans ce cas elle joue le rôle d’un mutex ou sémaphore. À titre informatif la variable atomique est juste une variable qui est indissociable et définit une seule fois. Elle peut être modifiée par des processus/ou sous processus, mais dans l’ordre chronologique (ordre total) c’est-à-dire si un processus A agis sur la variable atomique X avant le processus B. Les modifications apportées seront d’ordre total (A et ensuite B). L’ensemble des fonctions ou type atomique dans votre lien liste juste et type atomique qui est associé au type de la glib quant aux fonctions, ce sont juste les opérations atomiques possible et réalisable qui sont définies pour permettre la synchronisation des accès. Donc et probablement pour ce qui est de barrière mémorielle, il me semble que cela s’applique dans un contexte d’accès d’espaces mémoire atomique un Fetch-and-add ou Test-and-set, mais à vérifier.

à bientôt

[dalfab]

Il faut distinguer 3 caractéristiques distinctes nécessaires si plusieurs threads accèdent à une même variable :
* volatile : Les accès en lecture ou écriture doivent avoir une séquentialité garantie.
* atomique : Des opérations sur la variable sont insécables. N'est possible que si le processeur sait le garantir, donc seuls quelques types sont potentiellement atomiques (p.e bit, octet, mot, ...)
* barrières : Suite à une écriture, ou avant une lecture on a des garanties de ce qu'en voient les autres threads s'ils sont sur des processeurs différents. Car chaque processeur a une RAM cache et donc voit les écritures des variables modifiées ailleurs dans le désordre.
Ces trois caractéristiques sont à distinguer en C et en C++ (d'autres langages comme C# ou Java regroupent sous le nom volatile une variable qui est à la fois volatile et tous ses accès sont atomiques et memory_order_seq_cst).
Une atomique doit être volatile (pourquoi vouloir une action garantie garantie insécable si on ne la situe pas dans sa séquence).
Les barrières n'ont de sens que sur des actions atomiques mais une action atomique peut être memory_order_relaxed et donc sans contrainte de barrière.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
int a = 0;
volatile int b = 1;
atomic_int c = 0;
void fct () {
  a = 3;
  b = 4;     // 'b' est volatile : on est sûr que LE thread fera a=3 avant b=4 et ensuite b--
             // sans cela l'optimiseur pourrait directement écrire 3 dans 'b'
             // les autres processeurs peuvent eux voir 'a' modifié après 'b'.
  b--;
  c++;       // 'c' est atomique, si 2 threads appellent fct() "en même temps" 'c' vaudra 2
             // sans cela, les 2 c++ simultanés pourraient tous les 2 écrire 1 dans 'c'.
  atomic_store( &b , a );  // force un accès memory_order_seq_cst, TOUS les threads verront 'a' copié
             // dans 'b' après c++ et avant a--;
             // si on faisait b=a, le volatile ne garantirait ceci que pour LE thread.
  a--;
  atomic_store( &b , a , memory_order_release ); // les AUTRES thread qui lisent la valeur écrite ici dans 'b'
             // sont sûr que le résultat a-- est écrit en RAM de tous les processeurs
             // ici on ne garantit effectuées que les actions causes de 'b' (donc 'a' est en RAM)
}

L’utilisation d'objets de synchronisation (mutex, sémaphores, ...) permet aussi de gérer les "data races", ça protège des objets plus gros et ça inclut les 3 caractéristiques mais c'est plus lent et ne protège pas des interruptions.

[Luke spywoker]

Merci pour toutes ces réponses,

Je pensais juste a déclarer mes 2 variables (de type bool) de contrôles pour le play-mode de mon lecteur audio.

Car comme je disais dès fois il crash quand ont active le mode shuffle au mauvais moment rarement.

---

Donc dans un contexte monothread bien que 2 timeout sont en route dans mon programme a vie...???

Mais je pourrai très bien me servir du context de la GLib mainloop et/ou de sémaphores.

---

Ma question était simplement:

Est-ce que une variable atomique est une variable qui contient une valeur en plus de l'accès atomique.

Ou est ce seulement une alternative aux sémaphores et aux variables de contrôles ?

Merci pour vos réponses éclairées.

[dalfab]

Est-ce que une variable atomique est une variable qui contient une valeur en plus de l'accès atomique.

Ou est ce seulement une alternative aux sémaphores et aux variables de contrôles ?

Une variable atomique c'est une variable, elle n'a rien de plus que ce que son type indique (donc un atomic_int c'est un int sans rien de plus). On peut l'écrire ou la lire. S'en servir peut permettre d'éviter une protection par sémaphores, par exemple en utilisant un atomic booléen comme un arbitre de double buffering, on aura un mécanisme qui pourra éviter des objets de synchro.
C'est la manière d'utiliser la variable atomique qui va permettre de créer une protection, elle même n'a rien de "magique".

[Luke spywoker]

Merci pour cette réponse clair nette et précise.

[Mat.M]

Car comme je disais dès fois il crash quand ont active le mode shuffle au mauvais moment rarement.
.

l'atomicité d'une variable et le fait de la déclarer atomic,d'après ce que j'ai compris,c'est pour résoudre les problèmes de synchronisation.
Donc si tu as des crashes c'est que tu fermes mal des objets il faudrait revoir ton code
Ensuite dans un contexte monothread cela n'a pas d'intérêt car la variable en mémoire n'a de portée que dans le code dans lequel elle n'est utilisée c.a.d. qu'elle n'est pas modifiée par un autre processus (je ne sais pas si j'ai été clair là-dessus )

[Obsidian]

l'atomicité d'une variable et le fait de la déclarer atomic,d'après ce que j'ai compris,c'est pour résoudre les problèmes de synchronisation.

C'est vrai mais c'est une façon un peu rapide de résumer ça.

« atomique » signifie en soi « indivisible », de la même façon qu'une « dichotomie » revient à couper quelque chose en deux (ça peut être quelque chose d'aussi concret qu'une plaquette de beurre mais en informatique, ça va typiquement concerner soit les conversions du décimal vers le binaire, soit une liste triée quand on veut y faire une recherche). Je suppose que tu le sais très bien mais pour être totalement exact, c'est pour cela aussi que les atomes de matière portent ce nom en physique et en chimie : c'est l'unité élémentaire en dessous de laquelle il n'est plus possible de diviser une quantité de matière donnée. Bon, on s'est aperçu qu'il est tout-à-fait possible de les casser mais alors, on dénature ladite matière et ce que l'on obtient est différent.

L'atomicité en informatique concerne donc en général une opération quelconque : ici, il s'agit des accès à la mémoire mais dans le monde des bases de données, par exemple, c'est une des exigences du mécanismes des transactions, qui impliquent les fameuses propriétés ACID.

Ensuite dans un contexte monothread cela n'a pas d'intérêt car la variable en mémoire n'a de portée que dans le code dans lequel elle n'est utilisée c.a.d. qu'elle n'est pas modifiée par un autre processus (je ne sais pas si j'ai été clair là-dessus )

Même en contexte mono-thread, tu peux être confronté à ce problème, via les interruptions. Une IRQ peut très bien se déclencher en plein milieu d'une procédure censée être atomique et donc, par nature, être interrompue, ce qui en soi peut être un problème même si la routine appelée par l'IRQ ne modifie pas tes données. Ensuite, même si ce n'est pas un thread ou un processus concurrent qui accède à tes données, cela peut quand même concerner le matériel, via le DMA, spécialement si tu mets un sample en mémoire pour qu'il soit joué par la carton son ou si tu déposes une trame pour être émise sur le réseau via le contrôleur Ethernet ou autre. Maintenant, <stdatomic.h> ne couvre que les threads, donc…

Tu peux également déclarer des segments de mémoire partagée, qui peuvent être exploités par d'autres processus, mais là encore, même remarque qu'au dessus.