Is there an easy method of accessing custom System.Configuration-based configuration data through a thread-safe interface without requiring each execution context from loading/reloading configuration information which would be computationally burdensome?
System.Configuration classes, like most (all?) other classes in Microsoft’s .Net library documentation, are annotated with the following thread-safety information:
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.
By my reading of this, the ConfigurationSection objects returned from the ConfigurationManager.GetSection(string) and other similar methods (e.g. OpenExeConfiguration(string exePath).GetSection(string)) must not be assumed to be thread-safe and thus should not be used by multiple execution contexts. This prohibits storing a ConfigurationSection in a singleton that would otherwise be thread-safe because while the access to the section object may be safe, the members on the object itself are not safe.
Multiple calls to GetSection, however, are likely to require re-parsing of the configuration files and allocating new ConfigurationSection instances which has a high overhead considering the configuration is not likely to ever change after initialization. Further, copying the configuration data into another object that has been made thread-safe seems to defeat one of the main benefits of using the built-in configuration package in the first place (easy access to type-converted and validated configuration information without much boilerplate code).
So, is there a way to use System.Configuration in a thread-safe manner without resorting to excess parsing and allocations of configuration sections? Does implementing your own ConfigurationSection free you from the lack of guarantee provided by Microsoft even though you’re accessing it through the System.Configuration interfaces (and if so, how would you implement it to be thread-safe when access to the base ConfigurationSection‘s indexer is required for accessing the configured data)?
The instance returned from GetSection is not thread-safe. That means you need to add locking code in order to use it in your singleton.
Multiple calls do not re-parse the file, unless the file has changed. The data are cached in memory.
Your thread safety problem is easily solved by using locking (I’m not sure you’ll need to, unless you’re changing the configuration at runtime), and there is no performance problem.