views:

92

answers:

4

I am writing a cataloging application that parses through and extracts information from files and stores the information from each file in an object instance. In addition to the data extracted from the file the objects also have additional meta data properties (author, tags, notes, etc..) which later get stored in a separate XML file.

Extracting the data from the files is a time consuming process so I have it running on a separate thread. The properties extracted from the files will only ever come from the files, and thus have [ReadOnly] attributes to prevent the user from editing them. The meta data properties on the other hand are only populated by the user and thus are not read only. I'm allowing the user to view/edit these object through a PropertyGrid.

So if the extraction process is running on one thread populating the file properties of an object, is there any danger in letting the user edit the meta data properties at the same time? I'm trying to decided if I should use a modal interface that prevents the user from doing anything until the extraction is complete/canceled, or a non-modal interface that allows them to continue working while the extraction is running.

+1  A: 

In general, if the properties do not reference shared state, then they may be updated on separate threads with no trouble, even if they are part of the same object.

Jeffrey L Whitledge
A: 

You are free to do it, only if you are sure that the change of one property doesn't cause the change of the other that may be changed in another thread. Shortly if the properties don't have shared data, that will work great!

ArsenMkrt
+1  A: 

Assuming "normal" properties - eg., auto-implemented or simple field-backed:

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

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

There shouldn't be any issues related to changing the values on different threads. It's not necessary to synchronize writing to different variables.

However - if the PropertyGrid is showing the file properties (like FileAuthor) - you'd probably want to synchronize the reading (binding the PropertyGrid) and writing (the file extract) of those.

Mark Brackett
No all the properties are "normal" properties of primitive types
Eric Anastas
+2  A: 

To be specific to your question: No there is no problem.

What you should watch out for is that your properties written by the background thread are not read from the UI thread while they are being written. If you can't guarantee this, you must either use locks, marshall the write to the UI thread. (using control.Invoke() or BackgroundWorker or, make sure the write is an atomic write of pointer to an object that is not edited by the background thread while visible from the UI thread. I would not assume standard containers like List<T> are thread safe.

[wording changed]

jdv
So if the extraction thread updated the properties of the object the user was currently viewing in the propertygrid wouldn't update until the user reselected the object in the property grid? I wouldn't have a problem with this. I'm more concerned about the program crashing, or corrupting data.All the properties are primitive types like bool, int, double, and string.
Eric Anastas
I am raising this because of potential crashes, but it applies mostly to more complex types. Actually, a `double` is not guaranteed to be written atomic, so it might display wrong if reads and writes coincide. See the caution on: http://msdn.microsoft.com/en-us/library/system.double.aspx
jdv
I'm assuming it's very very very unlikely that a user is ever going to be able select an object at exactly the same time the properties are being written. Even if they did this wouldn't affect how the value is written correct? If the user was somehow very unlucky and ended up seeing a half written double value. Wouldn't they just see the correct value the next time they selected the object? Since I'm only displaying the values rather then depending on them for other logic in the program it doesn't seem like locks are essential.
Eric Anastas
It is indeed quite unlikely and from you told me, of no concern in your application. But I thought it was incorrect to just say there are no problems, I just wanted to make you aware of the unlikely worst case scenarios, and leave the judgement call up to you.
jdv
@Eric - you're spending a lot of effort trying to rationalize *not* using locks. I'd strongly suggest doing it the "correct" way, and optimizing if that's a performance problem. "Very, very, very unlikely" does not leave me with warm and fuzzies.
Mark Brackett
Yes I definitely prefer the correct way, which is why I ask these questions on SO. But there is a difference between a very very unlikely chance of displaying incorrect data, vs a very very unlikely chance of corrupting data. If the very rare problem can be fixed by the user selecting the object a second time then it's not as much of a concern to me as getting the rest of the meat of this program working.
Eric Anastas
@Mark - Agree. It's amazing how quickly something very, very, very unlikely starts happening as soon as a paying customer starts using your code.
Rory MacLeod