C bezpieczeństwo # wątek globalnych ustawień konfiguracyjnych

Question

W aplikacji C#, załóżmy, że mam jedną globalną klasę, która zawiera pewne elementy konfiguracji, tak jak poniżej:

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

static Options GlobalOptions; 

członków tej klasy będą zastosowania w różnych wątków:

Thread1: GlobalOptions.myConfigString = blah; 

podczas

Thread2: string thingie = GlobalOptions.myConfigString; 

Używanie blokady dostępu do GlobalOptions obiekt byłby również niepotrzebny blokować, gdy 2 wątki mają dostęp do różnych elementów, ale z drugiej strony tworzenie obiektu synchronizacji dla każdego członka wydaje się również nieco przesadzone.

Ponadto użycie blokady w opcjach globalnych spowodowałoby, że mój kod byłby mniej ładny; jeśli muszę napisać

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

wszędzie (i jest to bezpieczny wątku lub jest stringiwanttouse teraz tylko wskaźnik do myConfigString? Tak, jestem nowy w C# ....) zamiast

string stringiwanttouse = GlobalOptions.myConfigString; 

powoduje, że kod wygląda okropnie.

Więc ... Jaki jest najlepszy (i najprostszy!) Sposób na zapewnienie bezpieczeństwa gwintów?

Answer 1

Możesz zawinąć dane pole (myConfigString w tym przypadku) w usłudze i mieć kod w Get/Set, który używa albo Monitor.Lock albo Mutex. Następnie dostęp do właściwości blokuje tylko jedno pole i nie blokuje całej klasy.

Edycja: Kod dodanie

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

konfiguracje mogą być „globalny”, ale nie powinny one być wystawiony jako zmienną globalną. Jeśli konfiguracje się nie zmieniają, należy je wykorzystać do skonstruowania obiektów, które potrzebują tych informacji - ręcznie lub przez obiekt fabryczny. Jeśli zmienią się , należy użyć obiektu, który obserwuje plik konfiguracyjny/bazę danych/cokolwiek i implementuje Observer pattern.

zmienne globalne (nawet tych, które stało się wystąpienie klasy) są złe ™

Answer 3

Poniższa został napisany przed edytować 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. 
} 

---

Po tej edycji Mogę powiedzieć, że powinieneś zrobić coś jak wyżej i ustawić konfigurację tylko w jednym miejscu - klasie konfiguracji. W ten sposób będzie to jedyna klasa modyfikująca konfigurację w środowisku wykonawczym i tylko wtedy, gdy ma zostać pobrana opcja konfiguracji.

Answer 4

Co masz na myśli, mówiąc o bezpieczeństwie nici? To nie jest obiekt globalny, który musi być bezpieczny dla wątków, jest to kod dostępu. Jeśli dwa wątki napiszą do zmiennej składowej w pobliżu tej samej chwili, jedna z nich "wygra", ale czy to jest problem?Jeśli twój kod klienta zależy od tego, czy globalna wartość pozostaje stała, dopóki nie zostanie wykonana z jakąś jednostką przetwarzania, musisz utworzyć obiekt synchronizacji dla każdej właściwości, która musi być zablokowana. Nie ma na to świetnej okazji. Można tylko buforować lokalną kopię wartości, aby uniknąć problemów, ale zastosowanie tej poprawki zależy od okoliczności. Ponadto, nie utworzyłbym obiektu synchronizacji dla każdej właściwości domyślnie, ale zamiast tego, gdy zdasz sobie sprawę, że go potrzebujesz.