Is FileConfigurationSource thread-safe?

Topics: Enterprise Library Core, Validation Application Block
Mar 20, 2009 at 11:38 AM
Edited Mar 20, 2009 at 11:40 AM

I'm using the FileConfigurationSource to allow placing the configuration for the Validation Application Block in a separate configuration file (as discussed in this thread). In my application a single FileConfigurationSource instance is created per app domain and it is stored in a static field. The FileConfigurationSource lacks any documentation and I'm actually not sure if this is the correct usage of this type, so my question is: Is the FileConfigurationSource thread-safe and can it be used in the way I described?

Here's how I use it:

private static IConfigurationSource source = new FileConfigurationSource("Validation.config");

// This method can be called simultaneously from different threads.
public static ValidationResults ValidateEntity(object entity, string ruleSet)
{
    // is the use of static field 'source' safe here?
    Validator validator = ValidationFactory.CreateValidator(entity.GetType(), ruleSet, source);
            
    return validator.Validate(entity);
}

Mar 20, 2009 at 3:00 PM
Hi,

According to this http://technet.microsoft.com/en-us/library/microsoft.practices.enterpriselibrary.common.configuration.fileconfigurationsource.aspx it is thread safe.

Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com
Mar 20, 2009 at 3:23 PM
Edited Mar 22, 2009 at 12:12 PM
Thanks for the response.

The documentation you point at actually tells it's not thread-safe: "Any instance members are not guaranteed to be thread safe.". This however is the default text all types in the .NET framework get. Can you explain why you think it’s thread-safe?

 I also looked at the source code of the FileConfigurationSource (v4.1) and I noticed that there's a lot of locking going on. This at least gives the suggestion that the developers tried to make it thread-safe, but the implementation makes it quite difficult to reason about thread-safety.

Assuming the FileConfigurationSource isn't thread-safe, what is the performance penalty of recreating an instance over and over again?
Mar 20, 2009 at 4:14 PM
Oh sorry i missed that one. But i was just refering the way you described it. anyway, on your last question, IMHO, as i understand it allocates memory every time a instance is created unlike the static which only one instance is created.
Mar 20, 2009 at 4:15 PM
Edited Mar 20, 2009 at 4:16 PM
Oh sorry i missed that one. But i was just refering the way you described it. anyway, on your last question, IMHO, as i understand it allocates memory every time a instance is created unlike the static which only one instance is created. 

Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com
Mar 21, 2009 at 12:39 PM
Edited Mar 12, 2010 at 2:42 PM

I've looked again closely at the source code of the FileConfigurationSource and its internal FileConfigurationSourceImplementation and I'm starting to believe it is actually thread-safe. When you think about it, it has to be thread-safe, because all created FileConfigurationSource instances (for a single configuration file) use the same FileConfigurationSourceImplementation, stored as value in a static dictionary. The FileConfigurationSource routes all calls to the static FileConfigurationSourceImplementation. Therefore, when we assume that the FileConfigurationSourceImplementation is thread-safe, it implies that FileConfigurationSource is thread-safe to. And the other way around: when the FileConfigurationSourceImplementation wouldn’t be thread-safe, we would actually have a problem, because creating multiple FileConfigurationSource instances would still be unsafe.

Also, I don't agree with your performance statement. The difference in performance is actually more than a simple memory allocation. Like I said, the FileConfigurationSource isn't much more than a wrapper around a static dictionary of FileConfigurationSourceImplementation objects. This indeed means that there isn't much memory allocation happening under the covers. There is also some locking going on to protect that static dictionary (the EnsureImplementation method), but when you look closely, you'll see it is written as a double-checked lock, so even this doesn't have a big performance implication. However, the constructor of the FileConfigurationSource always calls the System.IO.File.Exists method, which does an OS call and most importantly a FileIOPermission.Demand() that triggers a stack walk. Therefore creating many FileConfigurationSource instances could have an impact on performance. I did some (unscientific) measurements and on my dev box instantiating a FileConfigurationSource took 0.06 milliseconds on average. This means that creating an instance for validating a group of objects wouldn't impact performance much, but creating a new instance for each object to validate could actually hurt performance. But as I concluded above, I don’t see a reason to create multiple instances anymore.