Привязка C#

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

поля Static не являются единственными вещами, которые нуждаются в синхронизации, любая общая ссылка, которая могла быть изменена, уязвима для проблем синхронизации.

class Foo
{
    private int count = 0;
    public void TrySomething()    
    {
        count++;
    }
}

Вы могли бы предположить, что два потока, выполняющие метод TrySomething, будут прекрасны. Но нет.

1. Поток чтения значение количества (0) в регистр, таким образом, это может быть увеличено.
2. Контекстное переключение! Планировщик потока решает, что поток A имел достаточно времени выполнения. Затем в строке Поток B.
3. Поток B читает значение количества (0) в регистр.
4. Поток B увеличивает регистр.
5. Поток B сохраняет результат (1) для подсчета.
6. Контекстное переключение назад к A.
7. Поток перезагрузки регистр со значением количества (0) экономил на своем стеке.
8. Поток инкременты регистр.
9. Поток A сохраняет результат (1) для подсчета.

Так, даже при том, что мы назвали количество ++ дважды, значение количества только что пошло от 0 до 1. Позволяет делают код ориентированным на многопотоковое исполнение:

class Foo
{
    private int count = 0;
    private readonly object sync = new object();
    public void TrySomething()    
    {
        lock(sync)
            count++;
    }
}

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

Между прочим, существует альтернативный способ сделать постепенное увеличение Int32s и Int64s ориентированный на многопотоковое исполнение:

class Foo
{
    private int count = 0;
    public void TrySomething()    
    {
        System.Threading.Interlocked.Increment(ref count);
    }
}

Относительно второй части Вашего вопроса, я думаю, что просто пошел бы с тем, какой бы ни легче читать, любое различие в производительности, там будет незначительно. Ранняя оптимизация является корнем всего зла, и т.д.

, Почему поточная обработка трудна