Потребность в энергозависимом модификаторе в проверенной дважды.NET привязки

достаточно блокировки lock. Сама спецификация языка MS (3.0) упоминает этот точный сценарий в §8.12, без упоминания volatile:

Лучший подход - синхронизировать доступ к статическим данным путем блокировки частный статический объект. Например:

класс Cache
{
 private static object synchronizationObject = new object();
 public static void Add(object x) {
 блокировка (Cache.synchronizationObject) {
 ...
 }
 }
 публичная статическая пустота Удалить(объект x) {
 блокировка (Cache.synchronizationObject) {
 ...
 }
 }
}

Я думаю, что нашел то, что искал. Подробности в этой статье - http://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S10.

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

Не думаю, что кто-то действительно ответил на вопрос , так что попробую.

Волатильность и первая , если (экземпляр == нуль) не "нужны". Блокировка сделает этот код потокобезопасным.

Итак, вопрос в том, зачем добавлять первую , если (экземпляр == null)?

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

Так что первая нулевая проверка добавляется в качестве очень быстрого способа узнать, нужна ли вам блокировка. Если вам не нужно создавать одиночку, вы можете полностью избежать блокировки.

Но вы не можете проверить, является ли ссылка нулевой, не заблокировав ее каким-то образом, потому что из-за кэширования процессора, другой поток может изменить ее, и вы прочитаете "просроченное" значение, которое приведет вас к неоправданному входу в блокировку. Но вы пытаетесь избежать блокировки!

Таким образом, вы делаете однокнопочную переменную волатильной, чтобы убедиться, что вы читаете последнее значение, не используя блокировку.

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

Теперь, это действительно полезно?

Ну, я бы сказал "в большинстве случаев, нет".

Если Singleton.instance может привести к неэффективности из-за замков, то почему вы звоните ему так часто, что это будет существенной проблемой? Вся суть одиночного вызова заключается в том, что он есть только один, поэтому Ваш код может прочитать и кэшировать ссылку на одиночный вызов один раз.

Единственный случай, когда такое кэширование невозможно, это когда у вас большое количество нитей (например, сервер, использующий новую нить для обработки каждого запроса, может создать миллионы очень коротких нитей, каждая из которых должна будет вызвать singleleton.instance один раз).

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

Довольно неплохой пост об использовании volatile с двойной проверкой блокировки:

http://tech.puredanger.com/2007/06/15/double-checked-locking/

В Java, если целью является защита переменной, то нет необходимости блокировать ее, если она помечена как volatile

AFAIK (и - принимай это с осторожностью, я не делаю много одновременных вещей) нет. Блокировка просто дает синхронизацию между несколькими соперниками (потоками). С другой стороны

volatile говорит вашей машине каждый раз пересматривать значение, чтобы вы не наткнулись на кэшированное (и неверное) значение.

Смотрите http://msdn.microsoft.com/en-us/library/ms998558.aspx и обратите внимание на следующую цитату:

Кроме того, переменная объявлена переменной нестабильной, чтобы гарантировать, что присваивание к переменной экземпляра завершается до того, как к ней будет получен доступ.

Описание нестабильной переменной: http://msdn.microsoft.com/en-us/library/x13ttww7%28VS.71. %29.aspx