Я читал следующую статью:http://msdn.microsoft.com/en-us/magazine/cc817398.aspx «Решение 11 вероятных проблем в вашем многопоточном коде» Джо Даффи

И это вызвало у меня вопрос: «Нам нужно заблокировать .NET Int32 при чтении его в многопоточном коде?»

Я понимаю, что если бы это был Int64 в 32-битном SO, он мог бы порваться, как это объясняется в статье. Но для Int32 я представил следующую ситуацию:

class Test
{
  private int example = 0;
  private Object thisLock = new Object();

  public void Add(int another)
  {
    lock(thisLock)
    {
      example += another;
    }
  }

  public int Read()
  {
     return example;
  }
}

Я не вижу причины включать блокировку в метод Read. Вы?

Обновить Основываясь на ответах (от Jon Skeet и ctacke), я понимаю, что приведенный выше код все еще уязвим для многопроцессорного кэширования (каждый процессор имеет свой собственный кэш, не синхронизированный с другими). Все три модификации ниже решают проблему:

Добавление в int пример свойства volatileВставка Thread.MemoryBarrier (); до фактического прочтения "Int пример"Прочитайте "int example" внутри "lock (thisLock)"

И я также считаю, что «volatile» - самое элегантное решение.