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 ?"

[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

[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 !

[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.