Bonjour OC,

je suis en train de découvrir  std::atomic grâce au livre de Mr Scott Meyers.

En lisant le passage cité du livre de Monsieur Scott Meyers que je mets après mon message, j'ai eu la pensée que il me semblait que dans l'exemple proposé dans son livre, l'utilisation de std::atomic<int> dans la classe Point permettrait de compter l'appel de la fonction à partir d'un nombre quelconque alors que l'utilisation d'une fonction compteur static ou d'une variable statique dans la classe Point permettrait au seul thread exécutant la fonction distanceFromOrigin() de compter le nombre d'appel.

Par une extrapolation un peu osé, std::atomic serait une sorte de généralisation d'un compteur static à  un nombre quelconque de threads.

Ma réflexion est-elle juste ? 

D'ailleurs, juste pour que je sois sûr, je voulais aussi de vous demander : quand il dit "un compteur dont les opérations sont vues par d'autres threads comme indivisibles", est-ce qu'il entend par ce que j'ai mis en caractères gras ?

------------------

Comme convenu, voici ce que dit Mr Scott Meyers :

Voici comment se servir d'un std::atomic pour compter des appels :

class Point{
pubic:
...
double distanceFromOrign() const noexcept
{
 ++callCount;    //Incrémentation atomique

 return std::sqrt((x*x)+ (y*y));
}

private:
mutable std::atomic<unsigned> callCount{0};
double x,y;
};

CREDIT : "Programmez efficacement en C++, de Scott Meyers (Dunod). Copyright 2016 Dunod pour la version française 978-2-10-074391-9, et 2015 Scott Meyers pour la versio d'origine 978-1-491-90399-5"

-
Edité par pseudo-simple 7 février 2019 à 17:07:47

>Ma réflexion est-elle juste ?

Non, aucun rapport entre un static tout moisi et std::atomic.

Peut-être que vous pensiez faire la même chose mais cela n'a rien à voir.

Si vous voulez un compteur static thread-safe, il vous faut utiliser un std::atomic pour ce compteur.

std::atomic, c'est pour éviter que des threads ne voient pas les mêmes valeurs, même s'ils tournent en même temps (le modèle mémoire du C++ ne garantit pas l'unicité de la valeur entre thread).

>est-ce qu'il entend par ce que j'ai mis en caractères gras ?

C'est le problème de base du multi-threading, commencez par lire un bouquin sur le sujet. Celui de Scott Meyers n'est pas fait pour cela.

Regardez bien le code de Scott Meyer, il n'y a pas de static, il y a un compteur par instance de Point, ce qui est impossible avec un static à la con.

S'il n'avait pas utiliser un std::atomic dans son code mais un simple unsigned, rien ne garantit que pendant qu'un thread exécute la ligne 6, un autre thread n'exécute pas cette même ligne 6.

Si c'est le cas,

- le thread A lit la valeur du compteur, incrémente sa valeur dans le registre du CPU |

- le thread B lit la valeur du compteur (qui n'a pas été modifié par le thread A), incrémente sa valeur dans le registre du CPU |

- le thread A sauvegarde sa valeur depuis le registre du CPU dans la RAM (la variable)

- le thread B sauvegarde sa valeur depuis le registre du CPU dans la RAM (la variable)

=> résultat, le compteur n'a pas compté l'un des appels, c'est ballot.

-
Edité par bacelar 8 février 2019 à 18:07:31

Merci Bacelar pour votre message. 

J'ai regardé dans le livre de Mr Lippman si il y a un cours sur le multithreading. Je n'ai point trouvé.

Auriez-vous un livre de référence qui ne soit pas épais, pas trop cher et achetable sur amazon, et qui permette de bien acquérir les bases du multi-threading en C++ spécifiquement avec les principes généraux d'architecture , registres, cache, ram...

Si c'est fait dans le livre de Mr Lippman, alors ce serait bien. Je n'ai pas vu.

Merci

-
Edité par pseudo-simple 7 février 2019 à 21:41:07

Le multi-threading est un concept avancé, cela ne serait pas étonnant qu'un bouquin qui prend un langage de programmation depuis le début n'aborde pas en profondeur ce sujet.

Il y a pléthore de bouquin juste sur ce sujet.

Malheureusement, j'ai "appris" le multi-threading "sur le tas", pas de références à donner, désolé.

Se limiter à un langage, le C++, c'est dommage car les meilleurs références ne sont pas forcément lié à ce langage ni à un langage en particulier. Des livres sur l'architecture hardware sont ardu mais précis sur le sujet.