Потреба у нестабільному модифікаторі при перевірці блокування в .NET

У кількох текстах сказано, що при впровадженні подвійно перевіреної блокування в .NET до поля, яке ви блокуєте, повинен застосовуватися мінливий модифікатор. Але чому саме? Розглядаючи наступний приклад:

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

чому "lock (syncRoot)" не забезпечує необхідну узгодженість пам'яті? Чи не правда, що після операції "lock" як читання, так і запис будуть мінливими, і тому буде досягнута необхідна послідовність?

Летючі непотрібні. Ну, як би **

volatileвикористовується для створення бар'єру пам'яті * між читанням і записом змінної.
lock, коли використовується, створює бар'єри пам'яті навколо блоку всередині lock, на додаток до обмеження доступу до блоку одним потоком.
Бар'єри пам'яті роблять це таким чином, що кожен потік читає найбільш поточне значення змінної (а не локальне значення, кешоване в якомусь регістрі), і що компілятор не впорядковує оператори. Використовувати volatileнепотрібно **, оскільки ви вже отримали замок.

Джозеф Альбахарі пояснює ці речі краще, ніж я коли-небудь міг.

І обов’язково ознайомтесь з посібником Джона Скіта з реалізації синглтона в C #

update :
* volatileпризводить до читання змінної до VolatileReads і запису до VolatileWrites, які на x86 та x64 на CLR реалізуються за допомогою a MemoryBarrier. Вони можуть бути більш дрібними в інших системах.

** моя відповідь правильна, лише якщо ви використовуєте CLR на процесорах x86 та x64. Це може бути правдою в інших моделях пам'яті, таких як Mono (та інші реалізації), Itanium64 та майбутньому обладнанні. Саме на це посилається Джон у своїй статті в "gotchas" про подвійне перевірене блокування.

Виконання одного з {позначення змінної як volatile, зчитування її Thread.VolatileReadабо введення виклику Thread.MemoryBarrier} може знадобитися для правильної роботи коду в ситуації слабкої моделі пам'яті.

Наскільки я розумію, на CLR (навіть на IA64) записи ніколи не впорядковуються (записи завжди мають семантику випуску). Однак на IA64 читання може бути впорядковано надходити перед записом, якщо вони не позначені як нестабільні. На жаль, я не маю доступу до обладнання IA64, з яким можна було б грати, тому все, що я скажу про це, було б спекуляцією.

Я також знайшов ці статті корисними:
http://www.codeproject.com/KB/tips/MemoryBarrier.aspx
стаття
Ванса Моррісона (все посилання на це, мова йде про подвійну перевірку блокування) стаття Кріса Брумме (все посилання на це )
Джо Даффі: Поламані варіанти подвійного перевірки блокування

Серія Луїса Абреу про багатопотоковість також дає хороший огляд концепцій
http://msmvps.com/blogs/luisabreu/archive/2009/06/29/multithreading-load-and-store-reordering.aspx
http: // msmvps. com / blogs / luisabreu / archive / 2009/07/03 / багатопотоковість-введення-пам'яті-огорожі.aspx

Існує спосіб реалізувати це без volatileполя. Я поясню це ...

Я думаю, що небезпечним є переупорядкування доступу до пам'яті всередині блокування, так що ви можете отримати не повністю ініціалізований екземпляр поза замком. Щоб цього уникнути, я роблю наступне:

public sealed class Singleton
{
   private static Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         // very fast test, without implicit memory barriers or locks
         if (instance == null)
         {
            lock (syncRoot)
            {
               if (instance == null)
               {
                    var temp = new Singleton();

                    // ensures that the instance is well initialized,
                    // and only then, it assigns the static variable.
                    System.Threading.Thread.MemoryBarrier();
                    instance = temp;
               }
            }
         }

         return instance;
      }
   }
}

Розуміння коду

Уявіть, що всередині конструктора класу Singleton є якийсь код ініціалізації. Якщо ці вказівки перевпорядковано після того, як поле встановлено з адресою нового об’єкта, то у вас є неповний екземпляр ... уявіть, що клас має такий код:

private int _value;
public int Value { get { return this._value; } }

private Singleton()
{
    this._value = 1;
}

А тепер уявіть виклик конструктора за допомогою нового оператора:

instance = new Singleton();

Це можна розширити до таких операцій:

ptr = allocate memory for Singleton;
set ptr._value to 1;
set Singleton.instance to ptr;

Що робити, якщо я впорядкую ці інструкції так:

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
set ptr._value to 1;

Чи це має значення? НІ, якщо ви думаєте про одну нитку. ТАК, якщо ви думаєте про декілька потоків ... що, якщо нитка перервана відразу після set instance to ptr:

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
-- thread interruped here, this can happen inside a lock --
set ptr._value to 1; -- Singleton.instance is not completelly initialized

Ось чого уникає бар'єр пам'яті, не дозволяючи переупорядковувати доступ до пам'яті:

ptr = allocate memory for Singleton;
set temp to ptr; // temp is a local variable (that is important)
set ptr._value to 1;
-- memory barrier... cannot reorder writes after this point, or reads before it --
-- Singleton.instance is still null --
set Singleton.instance to temp;

Щасливого кодування!

Думаю, насправді ніхто не відповів на запитання , тому спробую.

Нестійкі та перші if (instance == null)не є "необхідними". Блокування зробить цей код потокобезпечним.

Тож питання: чому б ви додали перше if (instance == null)?

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

Отже, перша нульова перевірка додана як дуже швидкий спосіб дізнатись, чи потрібен вам замок. Якщо вам не потрібно створювати синглтон, ви можете повністю уникнути блокування.

Але ви не можете перевірити, чи є посилання нульовим, не заблокувавши його якимось чином, оскільки через кешування процесора інший потік може його змінити, і ви прочитаєте "застаріле" значення, яке призведе до того, що ви введете блокування без потреби. Але ви намагаєтесь уникнути замку!

Таким чином, ви робите синглтон летким, щоб переконатись, що ви зчитуєте останнє значення, без необхідності використовувати замок.

Вам все ще потрібен внутрішній замок, оскільки енергонезалежний захищає вас лише під час одноразового доступу до змінної - ви не можете перевірити та встановити її безпечно, не використовуючи блокування.

Тепер, чи насправді це корисно?

Ну, я б сказав "у більшості випадків ні".

Якщо Singleton.Instance може спричинити неефективність через замки, то чому ви дзвоните йому так часто, що це може бути значною проблемою ? Вся суть синглтона в тому, що існує лише один, тому ваш код може читати та кешувати посилання на синглтон один раз.

Єдиний випадок, коли я можу придумати, де це кешування неможливе, - це коли у вас велика кількість потоків (наприклад, сервер, який використовує новий потік для обробки кожного запиту, може створювати мільйони дуже короткочасних потоків, кожен з яких який повинен був би зателефонувати Сінглтону. Екземпляр один раз).

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

Вам слід використовувати летючі елементи з шаблоном подвійної перевірки блокування.

Більшість людей вказують на цю статтю як на доказ того, що вам не потрібна мінливість: https://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S10

Але їм не вдається прочитати до кінця: " Заключне слово попередження - я лише здогадуюсь про модель пам'яті x86 за спостережуваною поведінкою на існуючих процесорах. Таким чином, техніки низького блокування також є тендітними, оскільки обладнання та компілятори з часом можуть стати більш агресивними Ось декілька стратегій, щоб мінімізувати вплив цієї крихкості на ваш код. По-перше, по можливості уникайте методів низького блокування. (...) Нарешті, припустимо найслабшу модель пам'яті з можливих, використовуючи летючі декларації, замість того, щоб покладатися на неявні гарантії . "

Якщо вам потрібно більш переконливо, прочитайте цю статтю про специфікацію ECMA, яка буде використана для інших платформ: msdn.microsoft.com/en-us/magazine/jj863136.aspx

Якщо вам потрібно ще переконливіше, прочитайте цю нову статтю про те, що можуть бути застосовані оптимізації, які заважають їй працювати без мінливості: msdn.microsoft.com/en-us/magazine/jj883956.aspx

Підсумовуючи, це "може" працювати для вас без мінливості на даний момент, але не варто писати правильний код і використовувати методи volatile або volatileread / write. Статті, в яких пропонується робити інакше, іноді не враховують деякі можливі ризики оптимізації JIT / компілятора, які можуть вплинути на ваш код, а також майбутні оптимізації, які можуть статися, які можуть зламати ваш код. Також, як згадувались припущення в останній статті, попередні припущення про роботу без мінливості вже можуть не мати ARM.

AFAIK (і - сприймайте це з обережністю, я не роблю багато одночасних речей) ні. Замок просто дає вам синхронізацію між кількома претендентами (нитками).

volatile, з іншого боку, говорить вашій машині щоразу переоцінювати значення, щоб ви не натрапили на кешоване (і неправильне) значення.

Див. Http://msdn.microsoft.com/en-us/library/ms998558.aspx та зверніть увагу на таку цитату:

Крім того, змінна оголошується мінливою, щоб забезпечити завершення присвоєння змінної екземпляра перед тим, як можна отримати доступ до змінної екземпляра.

Опис летких: http://msdn.microsoft.com/en-us/library/x13ttww7%28VS.71%29.aspx

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

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

lockДосить. Сама специфікація мови MS (3.0) згадує саме цей сценарій у п. 8.12, не згадуючи volatile:

Кращим підходом є синхронізація доступу до статичних даних шляхом блокування приватного статичного об’єкта. Наприклад:

class Cache
{
    private static object synchronizationObject = new object();
    public static void Add(object x) {
        lock (Cache.synchronizationObject) {
          ...
        }
    }
    public static void Remove(object x) {
        lock (Cache.synchronizationObject) {
          ...
        }
    }
}

Це досить хороший допис про використання енергонезалежних з подвійним перевіреним блокуванням:

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

У Java, якщо метою є захист змінної, вам не потрібно блокувати, якщо вона позначена як нестабільна