Discussion :

[halil.zakaria]

Bonjour,
je suis d�butant dans WIN32 multithreading,j'ai un simple code et des simples questions.

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
#include <iostream>
#include <Windows.h> 
#include <process.h>
#include <stdlib.h>
using namespace std;

typedef struct struct1
{
int entier;
char* description;

}struct1;


unsigned int __stdcall thread(void *param1)
{	struct struct1 *passed_struct;
	passed_struct = (struct struct1 *) param1;
	cout << passed_struct->entier<<"  ";
	cout<< passed_struct->description<<endl;
	
	passed_struct->entier=passed_struct->entier+1;		
	return(0);

}

int main()
{
	int i;
HANDLE handle[5];

struct1 doublet1;

doublet1.entier=0;
doublet1.description="something";


for(i=0;i<5;i++)
{

handle[i] = (HANDLE)_beginthreadex(0, 0, &thread, (void*)&doublet1, 0, 0);



}
WaitForSingleObject( handle1[0], INFINITE );
WaitForSingleObject( handle1[1], INFINITE );
WaitForSingleObject( handle1[2], INFINITE );
WaitForSingleObject( handle1[3], INFINITE );
WaitForSingleObject( handle1[4], INFINITE );
cout <<"final value is"<<doublet1.entier<<endl;

}

si c'est vrai chaque thread s"execute dans son stack,mais on dit que plusieurs thread dans le meme process partage une memoire partag�,est ce que le fait de referencer un objets et passer son addresse a multiples thread repr�sente la memoire partag� dont on parle.
et pour ma question � propos de mon code,je d�sire lancer 5 thread ,une seule thread peut incrementer le champs entier de la structure point� � la fois,comme ca la prochaine thread va lire cet objet refernc� mis � jour ainsi de suite?comme ce faire avec des mutex?

[ram-0000]

Effectivement, chaque thread poss�de sa propre pile. Par contre, tous les thread d'un m�me process partagent la m�me m�moire des donn�es.

Si plusieurs thread doivent atteindre la m�me variable, il faut alors prot�ger cette variable avec une section critique.

[Neckara]

Bonjour,

Si plusieurs thread doivent atteindre la m�me variable, il faut alors prot�ger cette variable avec une section critique.

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.

[ram-0000]

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

Tu as raison, ce qui va sans dire va mieux en le disant...

[Flob90]

@Neckara: �a d�pend des plateforme, d'o� la pr�sence de macro pour v�rifier le caract�re lock-free de ces types. Le mieux restant d'utiliser std::atomic.

[halil.zakaria]

je viens de lire que chaque thread pocc�de sa propre pile d'execution ce qui veut dire que toutes les variables locales sont detruites locequ'elles sont hors scope,par contre toute reservation de memoire (malloc,new) faite dans une thread (ou dans la fonction appelante la thread)et visible par toutes threads.en d'autre term ils partagent le Heap.

donc la portion critique de mon code est bien l'instruction:
passed_struct->entier=passed_struct->entier+1;
n'est ce pas ??

[Neckara]

donc la portion critique de mon code est bien l'instruction:
passed_struct->entier=passed_struct->entier+1;
n'est ce pas ??

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

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