2010-02-24 2 views
7

Я пишу приложение для каталогизации, которое анализирует и извлекает информацию из файлов и сохраняет информацию из каждого файла в экземпляре объекта. В дополнение к данным, извлеченным из файла, объекты также имеют дополнительные свойства метаданных (автор, теги, заметки и т. Д.), Которые затем сохраняются в отдельном файле XML.Можно ли разрешить двум потокам редактировать разные свойства одного и того же объекта одновременно?

Извлечение данных из файлов - это трудоемкий процесс, поэтому я запускаю его на отдельном потоке. Свойства, извлеченные из файлов, будут поступать только из файлов и, следовательно, имеют атрибуты [ReadOnly], чтобы пользователь не мог их редактировать. С другой стороны, свойства метаданных заполняются только пользователем и, следовательно, не читаются. Я разрешаю пользователю просматривать/редактировать этот объект через PropertyGrid.

Итак, если процесс извлечения выполняется на одном потоке, заполняющем свойства файла объекта, существует ли опасность, позволяя пользователю редактировать свойства метаданных одновременно? Я пытаюсь решить, должен ли я использовать модальный интерфейс, который мешает пользователю делать что-либо до завершения/отмены извлечения или немодального интерфейса, который позволяет им продолжать работать во время выполнения извлечения.

ответ

3

Для уточнения вопроса: Нет проблем.

Вы должны следить за тем, чтобы ваши свойства, написанные фоновым потоком, не читались из потока пользовательского интерфейса во время их написания. Если вы не можете этого гарантировать, вы должны либо использовать блокировки, либо маршировать запись в поток пользовательского интерфейса. (используя control.Invoke() или BackgroundWorker или, убедитесь, что запись является атомарной записью указателя на объект, который не редактируется фоновым потоком, хотя видно из потока пользовательского интерфейса. Я бы не предполагал, что стандартные контейнеры, такие как List<T>, являются потокобезопасными.

[измененная редакция]

+0

Итак, если поток извлечения обновил свойства объекта, который пользователь просматривал в PropertyGrid, не обновлялся до тех пор, пока пользователь не переустановит объект в сетке свойств? У меня не было бы проблем с этим. Я больше беспокоюсь о сбое программы или повреждении данных. Все про perties - это примитивные типы, такие как bool, int, double и string. –

+0

Я поднимаю это из-за потенциальных сбоев, но он применяется в основном к более сложным типам.На самом деле, «double» не гарантируется, что он написан атомом, поэтому он может отображаться неправильно, если чтение и запись совпадают. См. Предупреждение: http://msdn.microsoft.com/en-us/library/system.double.aspx – 2010-02-24 21:18:41

+0

Я предполагаю, что очень маловероятно, что пользователь когда-либо сможет выбрать объект точно в то же время записываются свойства. Даже если бы они это сделали, это не повлияло бы на то, как значение написано правильно? Если бы пользователю было как-то очень не повезло, и он увидел половину написанного двойного значения. Разве они не увидели бы правильное значение при следующем выборе объекта? Так как я только показываю значения, а затем в зависимости от них для другой логики в программе, это не похоже, что блокировки необходимы. –

1

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

0

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

1

Если предположить, что «нормальные» свойства - например, автоматическое реализуемый или просто поле спинками:

public class MyClass { 
    [ReadOnly] 
    public string FileAuthor { get; set; } 

    public string MetaDataAuthor { 
     get { return _metaDataAuthor; } 
     set { _metaDataAuthor = value; } 
    } 
    private string _metaDataAuthor; 
} 

Там не должно быть каких-либо вопросов, связанных с изменением значений в разных потоках. Нет необходимости синхронизировать запись с разными переменными.

Однако - если PropertyGrid показывает свойства файла (например, FileAuthor) - вы, вероятно, захотите синхронизировать чтение (связывание PropertyGrid) и запись (извлечение файла) из них.

+0

Не все свойства являются «нормальными» свойствами примитивных типов –