Discussion :

[Charlock]

Bonjour,

Je suis confronté au problème suivant : je travaille sur un projet C++ conséquent. Ce projet fait appel à une bibliothèque C et en particulier à une fonction, dont je peux modifier le code, mais pas la signature. Cette fonction utilise une variable globale. Le code ressemble donc à ça :

Code :

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

1
2
3
4
5
6
7
int* maVariableGlobale;
 
void maFonctionC( void ) {
   //J'utilise la variable globale
   if(maVariableLocale != NULL)
      printf("Variable = %d\n", *maVariableGlobale);
}

Jusque là tout va bien. Sauf que dorénavant, ce programme va devenir un programme multi-thread, et chaque thread (y compris le thread principal du programme) :

• fera appel à maFonctionC ;
• devra conserver une valeur différente de cette variable globale.

Je vois pour l'instant une solution, qui serait d'utiliser le Thread Local Storage pour gérer cela. Avec la bibliothèque boost, ça donnerait par exemple le code suivant :

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
boost:thread_specific_ptr<int> maVariableGlobale;
 
void maFonctionC( void ) {
   //Je locke un mutex
   if(maVariableGlobale.get() != NULL)
      printf("Variable = %d\n", maVariableGlobale.get());
   //Je relâche le mutex
}
 
void fonctionPrincipaleDeMonThread( void )
{
   //Je locke un mutex
   maVariableGlobale.reset(new int(1492));
   //Je relâche le mutex
}

Je cherche une autre solution, qui passerait par une autre chose que TLS et pourquoi pas par du code lock-free.

Merci d'avance pour vos réponses.

[Trademark]

Je ne te conseille pas de t'embarquer dans l'aventure du code lock-free car si t'es pas un spécialiste tu vas créer des bugs. Pourquoi la solution TLS ne te convient-elle pas ?

[Emmanuel Deloget]

Chaque thread doit avoir une valeur différente pour la variable, et tu ne souhaites pas utiliser TLS ? Ça me semble diablement étrange.

C'est exactement fait pour ça - donc pourquoi ?

L'alternative consisterait à avoir une variable globale par thread, et de changer le contenu de la variable globale que tu souhaite protéger de manière atomique avant chaque appel de la fonction - c'est, selon moi, une recette pour un désastre. Il y a 99% de chance que ça te pose problème à terme (par exemple, un appel à cette fonction que tu ne peut pas contrôler et hop ! la fonction traite la mauvaise valeur). Tu peux encapsuler ça dans la fonction elle même, mais dans ce cas tu va très nettement complexifier le code (la globale devient une liste de valeurs associée à un thread id ; pas des plus reluisants. Après, il existe des implémentations de hashmap ou de set qui sont lockfree - ce qui ne veut pas dire qu'elle sont plus performantes que les implémentations qui ne sont pas lockfree).

Bref : pourquoi cette réticence à utiliser TLS alors que tu te trouve exactement dans l'un des cas typique d'utilisation ?

[Charlock]

Merci pour vos réponses !

Le souhait de ne pas utiliser TLS vient de fortes contraintes de performances de cette partie du code. J'ai cru comprendre (c'est toujours délicat juste en lisant des forums, mais bon...) que l'implémentation TLS de boost n'était pas idéale, en terme de performances justement. Vu que je ne dispose pas de C++11, je ne peux pas non plus utiliser les fonctionnalités de la STL.

De plus, la fonction maFonctionC étant appelée beaucoup de fois, j'ai l'impression (erronnée ?) que des locks/unlocks répétés risquent de pénaliser sérieusement les performances.

[Trademark]

Tu as raison si ta fonction est appelée souvent, un mutex va considérablement ralentir l'appli (mais fait des tests de performances/profiling avant pour en être sur). Après il n'y a pas de solutions miracles, tu payes juste les pots cassés des gens qui ont utilisés des variables globales avant toi...

[Charlock]

Ok, c'est bien ce que je craignais. Je vais profiler tout ça pour avoir une idée plus précise des pertes.

Tu peux encapsuler ça dans la fonction elle même, mais dans ce cas tu va très nettement complexifier le code (la globale devient une liste de valeurs associée à un thread id ; pas des plus reluisants.

A quel problème fais-tu allusion exactement quand tu dis que ce n'est pas très reluisant ?

[Médinoc]

De plus, la fonction maFonctionC étant appelée beaucoup de fois, j'ai l'impression (erronnée ?) que des locks/unlocks répétés risquent de pénaliser sérieusement les performances.

Euh, j'ai du mal à voir ce que des "locks/unlocks répétés" ont à voir avec le TLS...

[Charlock]

Alors, sauf erreur de ma part, l'implémentation boost de TLS, implique d'utiliser un mutex pour protéger chaque accès au pointeur thread_specific_ptr. Je parlais de cela.

[Trademark]

Je pense pas qu'il faut un mutex vu que le storage va être spécifique à chaque thread, ce qui est le but, j'ai pas trop réfléchi dans les précédents posts... En plus la doc de Boost n'en parle pas.

[Médinoc]

Sur un système disposant de TLS, j’ose espérer que la bibliothèque reposera sur les services de l'OS. Dans l'exemple de Windows, le seul endroit que je vois où il pourrait falloir un lock (et encore, un algo lock-free peut suffire) c'est l'allocation d'un nouveau slot. Tout le reste est accessible directement depuis le Thread Environment Block, et on n'a pas besoin de lock pour y accéder (le pointeur est mis dans le registre FS lors de chaque changement de thread du processeur).

Il doit y avoir un truc similaire sur les unixoïdes...

[Iradrille]

De plus, la fonction maFonctionC étant appelée beaucoup de fois, j'ai l'impression (erronnée ?) que des locks/unlocks répétés risquent de pénaliser sérieusement les performances.

C'est un peu hors sujet, vu qu'il ne devrait pas y avoir de lock / unlock, mais niveau performance, les std::mutex / boost::mutex ne semblent pas utiliser les critical sections (du moins sur Windows, avec VS). Une gestion "manuelle" (utilisation de l'API Win32, ou équivalent sur Unix) peut être préférable si les lock / unlock sont trop lourd.