Discussion :

[flo_k]

Bonjour,

je programme une application qui lance plusieurs threads,

Les threads partagent une variable globale, en l'occurence, une grosse structure avec énormément de champ de toute sorte à l'intérieur.

Chaque thread accède en lecture ou en écriture aux champs de la structure mais rarement aux meme en meme temps et encore moins en lecture ou en écriture en meme temps.

Donc pour éviter les accès simultanées à ma structure partagée, j'ai utilisé qu'un seul verrou et je l'utilise pour vérouiller chaque section du thread qui accède a ma structure, peu importe le champ.

Donc je me pose des questions, initialement sans utiliser les verrous,
est ce que deux threads qui essayent de lire ou écrire deux champs different d'une meme structure pose problème ? ou ce n'est le cas que lorsque exactement la meme variable de la structure est accedé par plusieurs threads ?

Et pareil si un thread accède à l'indice 7 d'un tableau (tab[7]) et un autre accède au meme tableau mais d'indice différent (tab[8]) est ce que cela pose problème ?

Et donc en fonction, comment gérer cela,
créer un seul verrou pour toute la structure ? meme si ce n'est pas la meme variable de la structure qui est atteinte en meme temps ? les threads vont alors souvent perdre du temps à attendre. Ou alors créer un verrou pour chaque champ de ma structure ? certainement un gain de temps mais pas forcément très simple à gerer au niveau du code ?

Dernière chose, toujours théorique, je débute, je programme avec la librairie pthread, est ce que la création d'un mutex suffit pour résoudre le problème des "race conditions" & autres, ou comme il me semble l'avoir lu, il faut aussi ajouter des conditions (pthread_cond_t), or il me semble que celles ci ne servent qu'a synchroniser les threads, si l'ordre d'execution des threads m'importe peu et que je ne les synchronise pas suis-je quand meme à l'abri de toutes sortes de bugs et plantages (si on suppose que le code mis a part la gestion des threads, est niquel ) ?

Merci à vous.

[nicolas.sitbon]

Bonjour,

Bonjour

je programme une application qui lance plusieurs threads,

multithread, OK.

Les threads partagent une variable globale, en l'occurrence, une grosse structure avec énormément de champ de toute sorte à l'intérieur.

Pas bien les globales (même si parfois difficile de s'en débarasser).

Chaque thread accède en lecture ou en écriture aux champs de la structure mais rarement aux même en même temps et encore moins en lecture ou en écriture en même temps.

Donc pour éviter les accès simultanées à ma structure partagée, j'ai utilisé qu'un seul verrou et je l'utilise pour vérouiller chaque section du thread qui accède a ma structure, peu importe le champ.

Donc je me pose des questions, initialement sans utiliser les verrous,
est ce que deux threads qui essayent de lire ou écrire deux champs différent d'une même structure pose problème ? ou ce n'est le cas que lorsque exactement la même variable de la structure est accédée par plusieurs threads ?

ça n'est le cas que lorsque la même variable est accédé, ou champs d'une variable, puisque une structure est un aggrégat de variable.

Et pareil si un thread accède à l'indice 7 d'un tableau (tab[7]) et un autre accède au même tableau mais d'indice différent (tab[8]) est ce que cela pose problème ?

Non.

Et donc en fonction, comment gérer cela,
créer un seul verrou pour toute la structure ? même si ce n'est pas la même variable de la structure qui est atteinte en même temps ? les threads vont alors souvent perdre du temps à attendre. Ou alors créer un verrou pour chaque champ de ma structure ? certainement un gain de temps mais pas forcément très simple à gérer au niveau du code ?

Utiliser un style de programmation orienté objet, en faisant un type abstrait de donné, chaque champs de ta structure (objet) aura des fonctions setter et getter encapsulant cette logique de verrouillage pour chaque indépendamment des autres.

Dernière chose, toujours théorique, je débute, je programme avec la librairie pthread, est ce que la création d'un mutex suffit pour résoudre le problème des "race conditions" & autres, ou comme il me semble l'avoir lu, il faut aussi ajouter des conditions (pthread_cond_t), or il me semble que celles ci ne servent qu'a synchroniser les threads, si l'ordre d'exécution des threads m'importe peu et que je ne les synchronise pas suis-je quand meme à l'abri de toutes sortes de bugs et plantages (si on suppose que le code mis a part la gestion des threads, est niquel ) ?

Merci à vous.

ça dépend, en théorie comme tu l'as dit, si tu te moques de l'ordre dans lequel les threads s'exécutent, alors pas besoin de synchro, mais cela ne préserve pas forcément des bugs, un thread peut avoir besoin de se synchroniser sur autre chose qu'un autre thread, d'où les conditions.

[flo_k]

Ok merci,
j'ai programmé quelque chose comme ca :

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
 
ma structure
{
       type champ1;
       type champ2;
 
       ...
       ...
 
       verrou ver_champ1;
       verrou ver_champ2;
}
 
type getter_champ1()
{
      verouiller(ver_champ1);
      tmp = ma_structure.champ1;
      deverouiller(ver_champ1);
 
      retourner tmp;
}
 
void *tache1(void *tmp)
{
     //Je dois acceder au champ 1 de la structure
     ch1 = getter_champ1();
 
     ...
}
 
...
 
int main()
{
   initialise(ma_structure.ver_champ1);
   initialise(ma_structure.ver_champ2);
 
   ...
 
   // On lance les threads
}

Ca correspond vaguement à la solution que tu conseille ?

[bizulk]

Créer une variable globale donnant l'acces a plusieurs threads dont leur exécution est asynchrone n'est pas gênant, il faut bien qu'elle se partage des infos d'un manière ou d'une autre, et leur synchronisation via les mutex et sémaphore est prévue entre autre pour cela. Par contre si les retrouves partout dans tes fonctions sans les avoir passées en parametres tu risques de t'y perdre.

1) Le verrou sur une zone mémoire vise a préserver l'intégrité des données contenues auxquelles tu ne peux accéder en un cycle processeur.
Donc poser un verrou sur une variable de type 'int' (ie 32 bits pour un x86) est inutile, mais l'étude doit être faite pour une structure de taille supérieure à un mot processeur (ie 32 bits ...), car son acces est exécuté en plusieurs cycles processeurs et l'intégrité des données compromise.

2) Comme on te l'a dit deux cases d'un tableau en accès simultanés n'ont pas besoin d'un accès synchronisés DU MOMENT QUE LEUR SEMANTIQUE EST INDEPENDANTE. Si la modification de l'information d'une case rend obsolete lcelle des autres case tu devras synchroniser les accès. Et c'est la même chose pour tes structures.

En tenant compte de 1) et de 2) tu peux faire tes conclusions.
Grosso modo 'discutable' : si tu n'as fais que grouper des infos indépendantes : pas de synchro. Si certaines infos auquelles tu accèdes sont dépendantes l'une de l'autre tu synchronises.