Discussion :

[emmr.rida]

En faisant une recherche vite faite sur internet j'ai trouvé ces deux articles très intéressent :
http://the-lazy-programmer.com/blog/?p=39 utilisant boost
http://www.codeproject.com/KB/threads/xylock.aspx utilisant un minimum de l'api Windows

Je me demande qu'elle est la meilleur approche pour rendre un objet C++ Thread Safe :
- Poser un lock dans le début des codes que l'on désir marquer non réentrable.
- "Locker" totalement un objet ou une variable. (Premier article avec boost)
- Lever une exception lors d'un accès à un objet par un Thread autre que celui qui l'a crée. (DotNet)
- Je vais pas mentir et marquer un "etc." car franchement ces trois que je connais actuellement et ce poste est là pour m'aider à élargir mes horizons concernant le sujet.

[yamashi]

A partir du moment ou tu lock, tu perds tout l'intérêt du multi thread.
Il est donc complètement inutile de faire plusieurs thread car les lock (semaphores) sont très lent et donc tu perds en performance par rapport a un système simple sans lock.

[3DArchi]

Bonjour,

A partir du moment ou tu lock, tu perds tout l'intérêt du multi thread.
Il est donc complètement inutile de faire plusieurs thread car les lock (semaphores) sont très lent et donc tu perds en performance par rapport a un système simple sans lock.

Je ne comprends pas ta réponse. Le multi thread n'est pas forcément là pour améliorer les performances mais pour permettre l'exécution concurrente de différents morceaux d'un programme : par exemple compiler un projet et garder l'I.H.M active.

En faisant une recherche vite faite sur internet j'ai trouvé ces deux articles très intéressent :
http://the-lazy-programmer.com/blog/?p=39 utilisant boost
http://www.codeproject.com/KB/threads/xylock.aspx utilisant un minimum de l'api Windows

Je me demande qu'elle est la meilleur approche pour rendre un objet C++ Thread Safe :
- Poser un lock dans le début des codes que l'on désir marquer non réentrable.
- "Locker" totalement un objet ou une variable. (Premier article avec boost)
- Lever une exception lors d'un accès à un objet par un Thread autre que celui qui l'a crée. (DotNet)
- Je vais pas mentir et marquer un "etc." car franchement ces trois que je connais actuellement et ce poste est là pour m'aider à élargir mes horizons concernant le sujet.

Je ne sais pas quelle est la meilleure approche.
Cependant, il me paraît pertinent de protéger totalement un objet qui va être partagé entre plusieurs threads. Cela évite de se poser la question de "Qu'est ce qui est protégé et qu'est ce qui ne l'est pas ?"

[buzzkaido]

Tout dépend du contexte.

Pour un systeme simple, mais pas forcement performant, locker tout l'objet surement le plus efficace.

Par contre, pour tirer profit des performances du multi-thread, il faut se poser un peu plus de questions, notamment :

- combien de threads on besoin d'écrire dans l'objet ?
- combien de threads on besoin de lire dans l'objet ?
- est-ce que si un thread écrit dans un objet et qu'un thread essaie de lire en même temps, il est important que la lecture renvoi la nouvelle valeur ou est-ce que l'on peut renvoyer la valeur précédent l'écriture en cours ?

La 3eme question, c'est notamment en cas d'un thread de calcul et d'un thread d'affichage qui tournent pendant un certain temps : si l'affichage n'est pas toujours parfaitement à jour, c'est pas forcement grave.

En fonction des réponses à ces questions, il y a différentes solutions :

- lockfree (peut être très efficace si on a un seul thread qui écrit et plusieurs qui lisent)
- mutex
- section critique
....

Lockfree : plus d'infos ici : http://en.wikipedia.org/wiki/Lock-fr...ree_algorithms

C'est u peu plus complexe a implémenter, c'est surtout pénible à tester, mais j'ai déjà obtenu des gains de performances significatifs.

[Mac LAK]

Tout dépend de ce que fait ton objet... Le but étant de le rendre thread-safe, il est crucial de comprendre en quoi certaines méthodes / accesseurs ne le sont PAS.

Si l'objet est partagé entre plusieurs threads, il faut voir quelles sont les conditions d'interblocage et/ou de retours erronés en priorité.
Blinder à outrance de mutex ne sert en général à rien, sauf à ralentir tout ce qui utilise cet objet. Il faut en mettre dans 99% des cas (il est rare qu'une classe soit totalement réentrante de partout, ou alors, elle n'est que consultative !), mais parfois, ce sont des choses très simples comme un InterlockedIncrement qui suffisent... Dans d'autres cas, il te faudra utiliser des mutex nommés inter-processus.

Les causes principales de non-réentrance :

• Utilisation d'autres éléments que les paramètres passés à la méthode (attributs R/W, globales, etc...).
• Accès concurrent en écriture et lecture, la valeur lue/écrite ayant un impact crucial.
• Utilisation de ressources critiques non partageables (ex : sockets, certains handles, ports I/O et accès bas niveau, etc.).
• Méthode modifiant l'état de l'objet.
• Écriture de méthodes / classes singleton.
• etc.

Par contre, ces éléments garantissent une réentrance complète :

• Méthode n'utilisant absolument que ses propres paramètres, et aucun élément global (inclus les variables locales déclarées en "static").
• Élément ne pouvant être que lu, initialisé par exemple dans le constructeur et jamais modifié par la suite.
• De façon globale, éléments utilisés d'une seule et unique manière par tous les threads et dont la valeur / état réel n'impacte pas le fonctionnement des autres éléments.

Bref, la liste des problèmes de réentrance est vaste, voire infinie. Il est crucial que tu comprennes bien le concept d'atomicité, et de voir quelles sont les opérations qui doivent être atomiques, afin de pouvoir les protéger efficacement.

De façon générale, il faut limiter au maximum possible le code en section critique et penser toujours au pire des cas, notamment et surtout le fait que sauf mention contraire, aucune instruction du C/C++ n'est garantie comme atomique. Y compris des trucs "simples" comme un "i++" ou un "m=0"....

Enfin, un mutex ne prends pas forcément beaucoup de temps à gérer, tout dépend en fait de QUEL type de mutex tu te sers... Une fonction "Interlocked*" ne provoque aucun overhead habituellement, c'est juste un "raccourci" pour une instruction processeur particulière (qui est, elle, atomique) et qui n'aurait peut-être pas été utilisée par ton compilateur si tu t'étais contenté d'un simple "++". Tout dépend de ton but final : rendre ton objet "juste" thread-safe (et risquer le clash en interprocessus), ou le rendre directement process-safe, sachant que ce sera sûrement un bulldozer pour soulever une miette si ta classe n'est JAMAIS destinée à être utilisée en environnement multi-processus. Il faut choisir judicieusement le niveau de protection que l'on souhaite avoir.

De façon générale, plus un mutex est global au système (ex : un CreateMutex inter-processus par rapport à un CRITICAL_SECTION) et plus il est complexe (ex : mutex lecteurs/rédacteur par rapport à un "simple" mutex de section critique), plus il est lent et coûteux à utiliser.

[jabbounet]

A partir du moment ou tu lock, tu perds tout l'intérêt du multi thread.
Il est donc complètement inutile de faire plusieurs thread car les lock (semaphores) sont très lent et donc tu perds en performance par rapport a un système simple sans lock.

Ok, mais des l'instant ou tu as un code multi-threadé, tu te retrouve forcement avec des problématiques de ressources partagées,
le problèmes de ces ressources partagées est justement qu'elles font parties des section critiques et doivent être protégées (d'où les lock).


Exemple bête: Tu as un serveur multi-threadé et tu veux compter le nombre de transactions que ton serveur effectue. si tu ne protège pas ce compteur au moins en écriture tu va te retrouvé avec des valeurs débiles dès que deux thread s'amusent à incrémenter ce compteur en même temps.

Et pour ne pas te retrouver avec des valeurs coconne tu n'as que deux solution:
- le protéger avec des lock (sémaphore/mutex ou équivalent)
- le déclarer comme volatile (ce qui veux dire qu'il n'ira jamais se mettre dans les registres de ton processeur, mais que cela le protegera contre une double écriture)


pour moi le multi-thread ne peux pas être envisagé sans se poser des questions sur les sections critiques ou alors c'est que tes threads font des trucs totalement différents et pourrait a la limite être dans des applications séparées.

[jabbounet]

Ok, mais des l'instant ou tu as un code multi-threadé, tu te retrouve forcement avec des problématiques de ressources partagées,
le problèmes de ces ressources partagées est justement qu'elles font parties des section critiques et doivent être protégées (d'où les lock).


Exemple bête: Tu as un serveur multi-threadé et tu veux compter le nombre de transactions que ton serveur effectue. si tu ne protège pas ce compteur au moins en écriture tu va te retrouvé avec des valeurs débiles dès que deux thread s'amusent à incrémenter ce compteur en même temps.

Et pour ne pas te retrouver avec des valeurs coconne tu n'as que deux solution:
- le protéger avec des lock (sémaphore/mutex ou équivalent)
- le déclarer comme volatile (ce qui veux dire qu'il n'ira jamais se mettre dans les registres de ton processeur, mais que cela le protegera contre une double écriture)


pour moi le multi-thread ne peux pas être envisagé sans se poser des questions sur les sections critiques ou alors c'est que tes threads font des trucs totalement différents et pourrait a la limite être dans des applications séparées.

le tout est donc d'identifier les sections critique correctement pour ne pas dégrader les perfs.

[buzzkaido]

- le déclarer comme volatile (ce qui veux dire qu'il n'ira jamais se mettre dans les registres de ton processeur, mais que cela le protegera contre une double écriture)

Déclarer comme "volatile" assure l'accès concurrentiel ?

Ca m'etonne.

Certes, cela garantit que la données ne sera pas stockée dans un registre du processeur.

Donc un thread ne peut pas stocker une valeur dans un registre et travailler dessus pendant qu'un autre thread charge une valeur différente dans un registre.... etc...

Mais la donnée est stockée en mémoire, il est donc important d'en protéger l'écriture si plusieurs threads sont susceptibles d'y écrire en même temps.

Surtout sur un processeur multi-cœurs : ils ont plusieurs jeux de registres (1 par cœur) mais aussi plusieurs bus pour accéder à la mémoire ou au cache, et rien ne garantit que deux threads sur deux cœurs différents ne s'exécutent pas STRICTEMENT au même moment et écrivent dans la même zone mémoire, STRICTEMENT au même moment.

Volatile permet seulement, il me semble, d'assurer la cohérence en LECTURE :

Par exemple :

Code :

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

1
2
3
4
5
 
for (i=0; i<n ; i++)
{
   traiter(m_valeur);
}

Ici :
- si pendant la boucle un autre thread vient écrire dans le membre "m_valeur" pendant l'exécution de la boucle
- si la variable "m_valeur" a été stockée dans un registre par le compilo le temps de la boucle (pour optimiser)

Alors "m_valeur" ne sera pas mis à jour, et le traitement se fera toujours sur la valeur de départ.

Mais en ce qui concerne l'ecriture, il me semble que ça ne garantit rien. La seule solution, c'est le "test and swap"

Encore plus vrai sur un multi-coeur.

[buzzkaido]

Pardon, ce n'est pas "test and swap", mais bien "compare and swap"

Plus d'infos ici :

http://en.wikipedia.org/wiki/Compare-and-swap

Il s'agit pratiquement de LA SEULE opération du processeur (multi-coeur ou pas) qui soit garantie comme atomique.

Toutes les API de haut niveau (mutex, lock, spin-lock...) sont basées dessus.

C'est aussi ce qui permet de faire du "lock-free".

La lecture de cet article wikipedia et de l'article que j'ai donné précédemment permettent de comprendre beaucoup de choses sur comment ça fonctionne.

[3DArchi]

volatile indique simplement au compilo que la variable peut changer sans raison apparente. Donc il n'y a pas d'optimisation sur cette variable en la gardant dans un registre. Elle est récupérée à chaque fois en mémoire. Donc, comme dit précédemment volatile ne garantie rien contre les problèmes d'accès concurrent.

[Mac LAK]

Le modificateur "volatile" ne garantit absolument rien côté thread-safe, il garantit uniquement que la donnée sera systématiquement rechargée depuis son adresse et non pas maintenue dans un registre.

Cela sert (presque) exclusivement à mapper un port I/O afin de garantir qu'il y aura bel et bien toujours un accès I/O effectué et non pas l'utilisation d'une vieille valeur désormais incorrecte.

En dehors de la programmation système, cela ne sert presque que si tu as un attribut possédant un accesseur en écriture et AUCUN accesseur en lecture, ce qui te garantit alors que l'attribut sera bien toujours lu et sera cohérent s'il y a eu une écriture entre temps.

Toutefois, l'utilisation de "volatile" peut avoir un impact négatif assez lourd sur le code, car il y a alors de fortes chances que le cache soit plus ou moins inutilisé dessus, provoquant des accès mémoire "lents".

[ram-0000]

Cela sert (presque) exclusivement à mapper un port I/O afin de garantir qu'il y aura bel et bien toujours un accès I/O effectué et non pas l'utilisation d'une vieille valeur désormais incorrecte.

Cela sert aussi pour une variable utilisée à la fois par une interruption (ou un signal) et par le programme principal

[jabbounet]

volatile indique simplement au compilo que la variable peut changer sans raison apparente. Donc il n'y a pas d'optimisation sur cette variable en la gardant dans un registre. Elle est récupérée à chaque fois en mémoire. Donc, comme dit précédemment volatile ne garantie rien contre les problèmes d'accès concurrent.

effectivement je me suis un peu trompé de scope pour le le volatile, ça interviens plus dans du multi-tache que dans du multi-thread.....


Ceci pour savoir un peu les cas d'utilisation de volatile:
http://publications.gbdirect.co.uk/c..._volatile.html
http://embedded.over-blog.com/article-4590386.html

dès fois je parle trop vite....

[Luc Hermitte]

Ok, mais des l'instant ou tu as un code multi-threadé, tu te retrouve forcement avec des problématiques de ressources partagées,
le problèmes de ces ressources partagées est justement qu'elles font parties des section critiques et doivent être protégées (d'où les lock).


Exemple bête: Tu as un serveur multi-threadé et tu veux compter le nombre de transactions que ton serveur effectue. si tu ne protège pas ce compteur au moins en écriture tu va te retrouvé avec des valeurs débiles dès que deux thread s'amusent à incrémenter ce compteur en même temps.

Confie le comptage à un seul thread et poste lui des notifications d'incrémentation dans une file lock-free. => 0 lock
(je n'ai pas dis que c'était efficace dans ce cas, mieux vaut utiliser ici un simple compteur atomique).

Les zones partagées sont des zones de troubles. A chaque fois que l'on peut éviter cela, on s'y retrouve.

PS: je ne peux que conseiller la lecture des articles d'Herb Sutter sur le DDJ. Le MT est son dada en ce moment.

[jabbounet]

Confie le comptage à un seul thread et poste lui des notifications d'incrémentation dans une file lock-free. => 0 lock
(je n'ai pas dis que c'était efficace dans ce cas, mieux vaut utiliser ici un simple compteur atomique).

Les zones partagées sont des zones de troubles. A chaque fois que l'on peut éviter cela, on s'y retrouve.

PS: je ne peux que conseiller la lecture des articles d'Herb Sutter sur le DDJ. Le MT est son dada en ce moment.

Effectivement les articles ont l'air intéressants. je vais probablement les regarder de près car je suis sur ce genre de problèmes en ce moment.

Perso j'essaye d'éviter d'avoir des zones partagées, mais parfois il n'y a pas le choix.

[yamashi]

Je ne comprends pas ta réponse. Le multi thread n'est pas forcément là pour améliorer les performances mais pour permettre l'exécution concurrente de différents morceaux d'un programme : par exemple compiler un projet et garder l'I.H.M active.

Dans ce cas il est inutile de lock, si chaque thread a une tache spécifique et n'accède/modifie pas la mémoire des autres.
Dans la question du PO je pense qu'il veut traiter la même chose mais de façon parallèle.
Exemple : Parser une liste ou un vecteur.
Or si il doit lock a chaque accès au conteneur, l'accès sera 20 fois plus lent (prouver et vérifier par des tonnes de Benchmark).
Donc pour gérer ce problème sans le problème de lock, je découperais la liste en n liste (n étant le nombre de thread a utiliser) pour faire ce que je veux avec les données sans avoir besoin de lock.

Une application pleine de lock est une application mal pense, coder sur 1 thread n'est pas pareil que sur 2 ou plus, il faut penser différemment et non pas faire la même chose que sur le thread unique mais en mettant des lock partout !

Apres je ne connais pas son problème, mais les conteneur thread safe sont déjà un mauvais départ. Avant de vous soucier des zone critique, souciez vous de concevoir votre application de tel façon qu'il n'y en ai pas !

[Mac LAK]

Cela sert aussi pour une variable utilisée à la fois par une interruption (ou un signal) et par le programme principal

J'avais bien mis "(presque)"...

Toutefois, pour ma part, quand on commence à jouer avec les IT et les signaux, on approche significativement de la programmation système et non plus de la programmation applicative. En programmation applicative, "volatile" devrait être aussi peu utilisé que "register", c'est à dire "jamais" de préférence.