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