C# fil de sécurité des paramètres de configuration globale

Question

Dans une application C#, supposons que j'ai une seule classe mondiale qui contient des éléments de configuration, comme suit:

public class Options 
{ 
    int myConfigInt; 
    string myConfigString; 
    ..etc. 
} 

static Options GlobalOptions; 

les membres de cette classe seront utilisations à travers différents threads:

Thread1: GlobalOptions.myConfigString = blah; 

tout

Thread2: string thingie = GlobalOptions.myConfigString; 

Utilisation d'un cadenas pour l'accès aux GlobalOptions L'objet serait également inutile lorsque 2 threads accèdent à des membres différents, mais d'un autre côté, créer un objet de synchronisation pour chaque membre semble également un peu trop haut. De plus, utiliser un verrou sur les options globales rendrait mon code moins sympa je pense; si je dois écrire

string stringiwanttouse; 
lock(GlobalOptions) 
{ 
    stringiwanttouse = GlobalOptions.myConfigString; 
} 

partout (et est-ce thread-safe ou est stringiwanttouse maintenant juste un pointeur vers myConfigString? Oui, je suis nouveau à C# ....) au lieu de

string stringiwanttouse = GlobalOptions.myConfigString; 

cela rend le code horrible.

Alors ... Quelle est la meilleure (et la plus simple!) Façon d'assurer la sécurité des filetages?

Answer 1

Vous pouvez recouvrir le champ en question (myConfigString dans ce cas) dans une propriété et avoir du code dans le Get/Set qui utilise un Monitor.Lock ou un Mutex. Ensuite, l'accès à la propriété verrouille uniquement ce champ unique et ne verrouille pas la classe entière.

Edit: ajout de code

private static object obj = new object(); // only used for locking 
public static string MyConfigString { 
    get { 
     lock(obj) 
     { 
      return myConfigstring; 
     } 
    } 
    set { 
     lock(obj) 
     { 
      myConfigstring = value; 
     } 
    } 
} 

Answer 2

Vos configurations peuvent être 'globale', mais ils ne devraient pas être exposé comme une variable globale. Si les configurations ne changent pas, elles doivent être utilisées pour construire les objets qui ont besoin des informations - manuellement ou via un objet d'usine. Si elles peuvent changer, alors un objet qui regarde le fichier de configuration/base de données/tout et implémente le Observer pattern doit être utilisé.

Les variables globales (même ceux qui se trouvent être une instance de classe) sont une mauvaise chose ™

Answer 3

Ce qui suit a été écrit avant l'édition de l'OP:

public static class Options 
{ 
    private static int _myConfigInt; 
    private static string _myConfigString; 

    private static bool _initialized = false; 
    private static object _locker = new object(); 

    private static void InitializeIfNeeded() 
    { 
     if (!_initialized) { 
      lock (_locker) { 
       if (!_initialized) { 
        ReadConfiguration(); 
        _initalized = true; 
       } 
      } 
     } 
    } 

    private static void ReadConfiguration() { // ... } 

    public static int MyConfigInt { 
     get { 
      InitializeIfNeeded(); 
      return _myConfigInt; 
     } 
    } 

    public static string MyConfigString { 
     get { 
      InitializeIfNeeded(); 
      return _myConfigstring; 
     } 
    } 
    //..etc. 
} 

---

Après cette édition , Je peux dire que vous devriez faire quelque chose comme ci-dessus, et seulement configurer la configuration dans un seul endroit - la classe de configuration. De cette façon, il sera la seule classe à modifier la configuration au moment de l'exécution, et seulement lorsqu'une option de configuration doit être récupérée.

Answer 4

Qu'entendez-vous par sécurité des filetages ici? Ce n'est pas l'objet global qui doit être thread safe, c'est le code d'accès. Si deux threads écrivent dans une variable membre près du même instant, l'un d'entre eux va "gagner", mais est-ce un problème?Si votre code client dépend de la valeur globale restant constante jusqu'à ce que cela soit fait avec une unité de traitement, vous devrez créer un objet de synchronisation pour chaque propriété qui doit être verrouillée. Il n'y a pas de bon moyen de contourner cela. Vous pouvez simplement mettre en cache une copie locale de la valeur pour éviter les problèmes, mais l'applicabilité de cette correction dépend de votre situation. De plus, je ne créerais pas d'objet de synchronisation pour chaque propriété par défaut, mais plutôt que vous réaliserez que vous en aurez besoin.