С# параллелизм массива структур

Поскольку Instrument содержит два двойника (два 64-битных значения), вы не можете записать его атомарно (даже на 64-битных машинах). Это означает, что метод Clone никогда не сможет создать потокобезопасную копию без какой-либо синхронизации.

TLDR; Не используйте структуру, используйте неизменяемый класс.

Возможно, вам больше повезет с небольшим редизайном. Попробуйте использовать неизменяемые структуры данных и параллельные коллекции из платформы .NET. Например, сделайте свой Instrument неизменяемым классом:

// Important: Note that Instrument is now a CLASS!! 
public class Instrument
{
    public Instrument(double nos, double last)
    {
        this.NoS = nos;
        this.Last = last;
    }

    // NOTE: Private setters. Class can't be changed
    // after initialization.
    public double NoS { get; private set; }
    public double Last { get; private set; }
}

Таким образом, обновление Instrument означает, что вам нужно создать новый, что значительно упрощает рассмотрение этого вопроса. Когда вы уверены, что только один поток работает с одним Instrument, все готово, так как рабочий теперь может безопасно это сделать:

Instrument old = a[5];

var newValue = new Instrument(old.NoS + 1, old.Last - 10);

a[5] = newValue;

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

ОБНОВЛЕНИЕ

Перечитав ваш вопрос, я вижу, что неправильно его понял, так как один поток пишет не в Instrument, а пишет в значение инструмента, но решение практически одно и то же: использовать неизменяемые ссылочные типы. Один простой трюк, например, состоит в том, чтобы изменить вспомогательные поля свойств NoS и Last на объекты. Это делает их обновление атомарным:

// Instrument can be a struct again.
public struct Instrument
{
    private object nos;
    private object last;

    public double NoS
    {
        get { return (double)(this.nos ?? 0d); }
        set { this.nos = value; }
    }

    public double Last
    {
        get { return (double)(this.last ?? 0d); }
        set { this.last = value; }
    }
}

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

И знание того, что двойные числа могут быть записаны атомарно на 32-битных.

Нет, это не гарантируется:

12.5 Атомарность ссылок на переменные

Чтение и запись следующих типов данных должны быть атомарными: bool, char, byte, sbyte, short, ushort, uint, int, float и ссылочные типы. Кроме того, операции чтения и записи перечислимых типов с базовым типом из предыдущего списка также должны быть атомарными. Чтение и запись других типов, включая long, ulong, double и decimal, а также определяемые пользователем типы, не обязательно должны быть атомарными.

(выделено мной)

Никаких гарантий в отношении удвоения на 32-битной или даже на 64-битной системе нет. strcut, состоящий из 2 дублей, еще более проблематичен. Вам следует пересмотреть свою стратегию.

Вы можете (ab) использовать ReaderWriterLockSlim.

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

Не уверен, что я бы сделал это, если бы действительно не было альтернативы. Может сбивать с толку тех, кто поддерживает это в будущем.

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

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

Другой подход состоит в том, чтобы иметь переменную changeCount для каждого слота массива, которая увеличивается, так что два LSB равны «10» до того, как будет записана структура, и Interlocked.Increment на 2 после нее (см. примечание ниже). Прежде чем код прочитает структуру, он должен проверить, выполняется ли запись. Если нет, он должен выполнить чтение и убедиться, что запись не началась или не произошла (если запись произошла после начала чтения, вернуться к началу). Если запись выполняется, когда код хочет прочитать, он должен получить общую блокировку, проверить, выполняется ли запись, и если это так, использовать операцию блокировки, чтобы установить LSB changeCount и Monitor.Wait в блокировке. Код, написавший структуру, должен заметить в своем Interlocked.Increment, что LSB установлен, и должен Pulse заблокировать. Если модель памяти гарантирует, что чтение одним потоком будет обрабатываться по порядку, а запись одним потоком будет обрабатываться по порядку, и если только один поток будет когда-либо пытаться записать слот массива за раз, этот подход должен ограничьте многопроцессорные накладные расходы одной операцией Interlocked в случае отсутствия конфликтов. Обратите внимание, что перед использованием такого кода необходимо тщательно изучить правила о том, что подразумевается или не подразумевается моделью памяти, поскольку это может быть сложно.

Кстати, есть еще два подхода, которые можно было бы использовать, если бы вы хотели, чтобы каждый элемент массива был типом класса, а не структурой:

1. Use an immutable class type, and use `Interlocked.CompareExchange` any time you want to update an element. The pattern to use is this:

     MyClass oldVal,newVal;
     do
     {
       oldVal = theArray[subscript];
       newVal = new MyClass(oldVal.this, oldVal.that+5); // Or whatever change
     } while (Threading.Interlocked.CompareExchange(theArray[subscript], newVal, oldVal) != oldVal);
   

   This approach will always yield a logically-correct atomic update of the array element. If, between the time the array element is read and the time it is updated, something else changes the value, the `CompareExchange` will leave the array element unaffected, and the code will loop back and try again. This approach works reasonably well in the absence of contention, though every update will require generating a new object instance. If many threads are trying to update the same array slot, however, and the constructor for `MyClass` takes any significant amount of time to execute, it's possible for code to thrash, repeatedly creating new objects and then finding out they're obsolete by the time they could be stored. Code will always make forward progress, but not necessarily quickly.
2. Use a mutable class, and lock on the class objects any time one wishes to read or write them. This approach would avoid having to create new class object instances any time something is changed, but locking would add some overhead of its own. Note that both reads and writes would have to be locked, whereas the immutable-class approach only required `Interlocked` methods to be used on writes.

Я склонен думать, что массивы структур лучше подходят для хранения данных, чем массивы объектов класса, но оба подхода имеют свои преимущества.

Хорошо, так что подумал об этом за обедом.

Я вижу два, возможно, 3 решения здесь.

Первое важное замечание: идея неизменяемости не работает в моем случае использования, потому что у меня есть две службы, работающие параллельно и записывающие в NoS и Last независимо друг от друга. Это означает, что мне потребуется дополнительный уровень логики синхронизации между этими двумя службами, чтобы гарантировать, что пока новая ссылка создается одной службой, другая не делает то же самое. Классическая проблема состояния гонки, поэтому определенно не подходит для этой проблемы (хотя да, я мог бы иметь рефери для каждого дубля и делать это таким образом, но в этот момент это становится смешно)

Решение 1 Блокировка всего кэша. Возможно, используйте спин-блокировку и просто заблокируйте все обновления и моментальный снимок (с помощью memcpy). Это самое простое и, вероятно, совершенно нормальное для томов, о которых я говорю.

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

Решение 3 Не думаю, что это сработает, но как насчет блокировки записи во все дубликаты, а затем просто использования memcopy. Я не уверен, что я получу разрыв двойников, хотя? (помните, меня не волнует разрыв на уровне структуры).

Если решение 3 работает, то я предполагаю, что это лучшая производительность, но в остальном я больше склоняюсь к решению 1.