Потокобезопасность C# глобальных параметров конфигурации

Вы можете обернуть рассматриваемое поле (в данном случае myConfigString) в Свойство и иметь код в Get / Set, который использует Monitor.Lock или Mutex. Затем доступ к свойству блокирует только это отдельное поле и не блокирует весь класс.

Изменить: добавление кода

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

Перед редактированием 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. 
}

После этого редактирования я могу сказать, что вы должны сделать что-то подобное вышеупомянутому и установить конфигурацию только в одном месте - в классе конфигурации. Таким образом, это будет единственный класс, изменяющий конфигурацию во время выполнения, и только тогда, когда необходимо получить параметр конфигурации.

Ваши конфигурации могут быть «глобальными», но они должны , а не быть представлены как глобальная переменная. Если конфигурации не меняются, их следует использовать для создания объектов, которым нужна информация - вручную или с помощью фабричного объекта. Если они могут изменяться, то следует использовать объект, который наблюдает за файлом конфигурации / базой данных / всем остальным и реализует шаблон наблюдателя .

Глобальные переменные (даже те, которые оказались экземпляр класса) являются Bad Thing ™

Что здесь подразумевается под безопасностью потоков? Это не глобальный объект, который должен быть потокобезопасным, это код доступа. Если два потока пишут в переменную-член почти в один и тот же момент, один из них «выиграет», но это проблема? Если ваш клиентский код зависит от того, чтобы глобальное значение оставалось постоянным до тех пор, пока это не будет выполнено с помощью некоторой единицы обработки, вам нужно будет создать объект синхронизации для каждого свойства, которое необходимо заблокировать. Нет никакого отличного способа обойти это. Вы можете просто кэшировать локальную копию значения, чтобы избежать проблем, но применимость этого исправления будет зависеть от ваших обстоятельств. Кроме того, я бы не стал создавать объект синхронизации для каждого свойства по умолчанию, но вместо этого, как вы понимаете, он вам понадобится.