title: Thread safe usage of System.Configuration
body: <p>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?</p>
  
  <p>System.Configuration classes, like most (all?) other classes in Microsoft's .Net library documentation, are annotated with the following thread-safety information:</p>
  
  <blockquote>
    <p>Any public static (Shared in Visual Basic) members of this type are thread safe. 
    Any instance members are not guaranteed to be thread safe.</p>
  </blockquote>
  
  <p>By my reading of this, the <code>ConfigurationSection</code> objects returned from the <code>ConfigurationManager.GetSection(string)</code> and other similar methods (e.g. <code>OpenExeConfiguration(string exePath).GetSection(string)</code>) must not be assumed to be thread-safe and thus should not be used by multiple execution contexts.  This prohibits storing a <code>ConfigurationSection</code> 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.</p>
  
  <p>Multiple calls to <code>GetSection</code>, however, are likely to require re-parsing of the configuration files and allocating new <code>ConfigurationSection</code> 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).</p>
  
  <p>So, is there a way to use <code>System.Configuration</code> in a thread-safe manner without resorting to excess parsing and allocations of configuration sections?  Does implementing your own <code>ConfigurationSection</code> free you from the lack of guarantee provided by Microsoft even though you're accessing it through the <code>System.Configuration</code> interfaces (and if so, how would you implement it to be thread-safe when access to the base <code>ConfigurationSection</code>'s indexer is required for accessing the configured data)?</p>