Является ли этот код потокобезопасным?

Question

У меня есть класс с несколькими свойствами. При каждом обновлении значения вызывается метод Store, который хранит все поля (в файле).

private int _Prop1; 
public int Prop1 { 
    get { 
     return _Prop1; 
    } 
    set { 
     _Prop1 = value; 
     Store(); 
    } 
} 

// more similar properties here... 

private XmlSerializer _Ser = new ...; 
private void Store() 
{ 
    lock (_Ser) { 
     using (FileStream fs = new ...) { 
      _Ser.Serialize (fs, this); 
     } 
    } 
} 

Этот дизайн нить-сейф?

(Кстати, если вы можете думать о более соответствующей подписи, не стесняйтесь редактировать).

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

Уточнение: Свойства не будут устанавливаться очень часто, но они могут быть установлены одновременно. Важно иметь действительный файл большую часть времени.

Если поток изменит свойство относительно значения свойства, он должен заблокировать весь объект для синхронизации с другими потоками. Это в основном то же самое, что и при блокировке на List при перечислении и не несет ответственности за этот класс.

Answer 1

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

Мелкозернистая блокировка, как это, как правило, является проблемой. Клиентский код может быть занят, изменяя более одного свойства класса. Вы получите частичное обновление, если возникает исключение, создавая файл, который содержит сериализованное состояние, которое является недопустимым и может вызвать проблемы при чтении. Вам понадобится нечто вроде пары BeginUpdate(), EndUpdate().

Answer 2

Это зависит от того, что вы звоните на разные темы.

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

Answer 3

Я бы предложил использовать какой-то Mutex, чтобы гарантировать, что данные только сериализованы в определенной точке, это может сделать так же, как обновление изменится или вот-вот изменится.

Следующая ссылка приведет вас простой пример на веб-сайте MSDN, что следует надеяться продемонстрировать это для вас:

Mutex Example

Answer 4

No.

В случае, если вы хотите синхронизировать свойства theirself , этот код не является потокобезопасным, так как «блокировка» не находится в значении _Prop1, а только на _Ser. Действительно, когда поток получает свойство, свойство может быть установлено другим потоком.

Даже процесс сериализации, _Ser доступ к свойствам, которые могут быть изменены другими потоками при выполнении (в то время как _Ser работает, другой набор потоков Prop1).

Этот код фактически запрещает использование объекта XmlSerialize _Ser несколькими потоками. Если это то, что вы хотите получить ...

---

Ответ существенно зависит от того, что вы хотите получить.

Answer 5

Если свойство Prop1 может быть вызвано из нескольких потоков, сделайте поле _Prop1volatile.

private volatile int _Prop1; 

Из MSDN,

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

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

Answer 6

Небезопасный поток, если тип свойства не является атомарным.

Простой примером, с нитями А и В.

A: Prop1 = foo 
A: Store() 
A: ... store saves foo.Var1 
B: Prop1 = bar 
A: ... store saves bar.Var2 (instead of foo.Var2) 

Целостность данных, возможно, нарушена. Даже с такими же простыми, как Int64, проблемы могут возникать в теории.

Помещение другого lock(_Ser) в сеттер поможет.