Должен ли потокобезопасный класс иметь в конце конструктора барьер памяти?

Lazy<T> - очень хороший выбор для потоковой инициализации. Я считаю, что потребителю следует предоставить следующее:

var queue = new Lazy<ThreadSafeQueue<int>>(() => new ThreadSafeQueue<int>());

Parallel.For(0, 10000, i =>
{

    else if (i % 2 == 0)
        queue.Value.Enqueue(i);
    else
    {
        int item = -1;
        if (queue.Value.TryDequeue(out item) == true)
            Console.WriteLine(item);
    }
});

Должен ли потокобезопасный класс иметь в конце конструктора барьер памяти?

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

Я попытаюсь ответить на этот интересный и хорошо сформулированный вопрос, основываясь на комментариях Серви и Дугласа, а также на информации, полученной из других связанных вопросов. Все, что изложено ниже, является всего лишь моими предположениями, а не достоверной информацией из авторитетного источника.

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

2. Добавление строки Thread.MemoryBarrier(); в конце конструктора недостаточно, чтобы сделать конструктор потокобезопасным, потому что этот оператор влияет только на поток, который запускает конструктор¹. Другие потоки, которые могут одновременно обращаться к находящемуся в стадии разработки экземпляру, не затрагиваются. Видимость памяти является кооперативной, и один поток не может изменить то, что видит другой поток, изменяя поток выполнения другого потока (или делая недействительным локальный кеш ядра ЦП, на котором работает другой поток) некооперативным образом.

3. Правильный и надежный способ гарантировать, что все потоки видят экземпляр, имеющий допустимое состояние, - это включить надлежащие барьеры памяти во все потоки. Этого можно добиться, объявив экземпляр как volatile < / a>, если это поле класса, или иным образом с использованием методов статического _ 3_ класс:

ThreadSafeQueue<int> queue = null;

Parallel.For(0, 10000, i =>
{
    if (i == 0)
        Volatile.Write(ref queue, new ThreadSafeQueue<int>());
    else if (i % 2 == 0)
        Volatile.Read(ref queue)?.Enqueue(i);
    else
    {
        int item = -1;
        if (Volatile.Read(ref queue)?.TryDequeue(out item) == true)
            Console.WriteLine(item);
    }
});

В этом конкретном примере было бы проще и эффективнее создать экземпляр переменной queue перед вызовом метода Parallel.For. Это сделает ненужными явные Volatile вызовы. Метод Parallel.For использует Tasks внутри, а TPL включает соответствующие барьеры памяти в начале / конце каждой задачи. Барьеры памяти неявно и автоматически создаются инфраструктурой .NET с помощью любого встроенного механизма, который запускает поток или вызывает выполнение делегата в другом потоке. (цитирование)

Повторюсь, я не уверен на 100% в правильности представленной выше информации.

¹ _{Цитата из документации метода Thread.MemoryBarrier: Синхронизирует доступ к памяти следующим образом: процессор, выполняющий текущий поток, не может переупорядочить инструкции таким образом, чтобы обращения к памяти до вызова MemoryBarrier() выполнялись после обращений к памяти, следующих за вызовом _12 _.}