_FR>>Огорчает нежелание (непонимание ) автора использовать модификатор readonly в объявлении "объекта синхронизации".

object syncRoot = new object();

readonly object syncRoot = new object();

T* const field; //константный указатель

const T* field; //указатель на константу

L>Думаю, .Den неспроста выделил пример с присваиванием.

Как правило, любое поле, доступное нескольким потокам, должно читаться и записываться с блокировкой. Даже в самом простом случае, операции присваивания одиночному полю, необходима синхронизация. В следующем классе ни приращение, ни присваивание не потокобезопасны:

Безопасность инициализации

Новая модель памяти JMM также старается предоставить новые гарантии безопасности инициализации. То есть, если объект соответствующим образом сконструирован (то есть ссылка на объект не опубликована, пока конструирование не завершено), тогда все потоки будут видеть значения его полей final, которые были установлены конструктором, независимо от того, используется ли синхронизация, чтобы передать ссылку из одного потока другому. Более того, переменные, которые могут быть доступны через поле final должным образом сконструированного объекта, например поля объекта, на который ссылается поле final, также гарантированно видимы другим потокам. Это значит, что если поле final содержит ссылку на, скажем, LinkedList, кроме видимости правильного значения ссылки другим потокам, содержимое этого LinkedList во время конструирования будет доступно другим потокам без синхронизации. Результат этого — значительное усиление значения final, то есть поля final могут быть безопасно доступны без синхронизации, и компиляторы могут предположить, что поля final не изменятся, и следовательно смогут оптимизировать множественные выборки.

Final значит final

Механизм, по которому поля final могли менять свое значение под старой моделью памяти был описан в Части 1 — в отсутствии синхронизации другой поток мог сначала видеть значение по умолчанию для поля final, а позже видеть правильное значение.

Под новой моделью памяти есть что-то похожее на отношения по схеме происходит-прежде между записью поля final в конструкторе и начальной загрузкой общедоступной ссылки на этот объект в другом потоке. Когда конструирование завершается, все записи в полях final (и переменных, доступных косвенно через эти поля final) становятся "заблокированными", и любой поток, который содержит ссылку на этот объект, после блокировки будет гарантированно видеть все заблокированные поля для всех заблокированных значений. Записи, которые инициализируют поля final, не будут перераспределяться с операциями, следующими за блокировкой, связанной с конструктором.

Вместо блокировки с двойной проверкой используйте идиому Initialize-on-demand Holder Class, которая обеспечивает ленивую инициализацию, потокобезопасность, и работает быстрее и не так запутанно как блокировка с двойной проверкой:

Листинг 2. Идиома Initialize-On-Demand Holder Class

private static class LazySomethingHolder {
  public static Something something = new Something();
}

...

public static Something getInstance() {
  return LazySomethingHolder.something;
}

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

class ThreadUnsafe 
{
  static object locker = new object();
  static int x;
 
  static void Increment()
  {
    lock (locker)
      x++;
  }


  static void Assign()
  {
    lock (locker)
      x = 123;
  }
}

class Test
{
  static object syncLock = new object();

  static void Proc1() {
    lock(syncLock) {
      // bla-bla-bla
    }//lock
  }

  static void Proc2() {
    lock(syncLock) {
      // bla-bla-bla
    }//lock
  }

  static void ProcXXX() {
    lock(syncLock) {
      syncLock = 8; // Без readonly этому нично не мешает. 
                    // Грабли в этом переприсвоении читателю предлагается найти самому ;о)
    }//lock
  }
}

Термин переупорядочивание используется для описания нескольких классов реальных и очевидных перераспределений операций с памятью:

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

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

volatile boolean initialized = false;
// запретили initialized хранить в локальной памяти:
// кэши, регистры, аппаратные средства, оптимизация программы в процессе компилирования и т.п.
// и наивно надеемся, что все будет OK

// В потоке_1
HashMap config = new HashMap();
init(config);
initialized = true;

// В потоке_2
while (!initialized) 
    sleep();
// инициализация закончена, начинаем использовать config
config.get("someProperty"); // получаем null, что такое?

f()
{
lock(this.myInt)
{
}
}

F1()
{
this.myInt += 10;
}

using System;
using System.Threading;

namespace Rsdn.Threads {
    public class MutableLockerTest {
        private static object locker = new object();
        private static bool created = false;

        private static void Go() {
            lock (locker) {
                Console.WriteLine("Enter");
                locker = new object();
                if (!created) { // просьба, тут не пинать из-за отсутствия синхронизации, это просто тест
                    created = true;
                    new Thread(Go).Start();
                }
                Thread.Sleep(TimeSpan.FromSeconds(5));
                Console.WriteLine("Exit");
            }
        }

        private static void Main() {
            Go();
        }
    }
}

What is the practical implication of this? Consider the standard double-locking protocol:

if (a == null) {
    lock(obj) {
        if (a == null) a = new A();
  }
}

This is a common technique for avoiding a lock on the read of ‘a’ in the typical case. It works just fine on X86. But it would be broken by a legal but weak implementation of the ECMA CLI spec. It’s true that, according to the ECMA spec, acquiring a lock has acquire semantics and releasing a lock has release semantics.

In terms of the above, the memory model for X86 can be described as:



1. All stores are actually store.release.
2. All loads are normal loads.
3. Any use of the LOCK prefix (e.g. ‘LOCK CMPXCHG’ or ‘LOCK INC’) creates a full fence.