Я читал следующую статью: 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 example" свойства "volatile"
- Вставка Thread.MemoryBarrier(); перед фактическим чтением "int example"
- Прочитайте "int example" внутри "lock (thisLock)"
И я также считаю, что "volatile" - самое изящное решение.