{"id":4359,"date":"2014-03-30T10:03:02","date_gmt":"2014-03-30T10:03:02","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2014\/03\/30\/thread-safe-usage-of-system-configuration-collection-of-common-programming-errors\/"},"modified":"2014-03-30T10:03:02","modified_gmt":"2014-03-30T10:03:02","slug":"thread-safe-usage-of-system-configuration-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2014\/03\/30\/thread-safe-usage-of-system-configuration-collection-of-common-programming-errors\/","title":{"rendered":"Thread safe usage of System.Configuration-Collection of common programming errors"},"content":{"rendered":"<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>\n<p>System.Configuration classes, like most (all?) other classes in Microsoft&#8217;s .Net library documentation, are annotated with the following thread-safety information:<\/p>\n<blockquote>\n<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>\n<\/blockquote>\n<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>\n<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>\n<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&#8217;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>&#8216;s indexer is required for accessing the configured data)?<\/p>\n","protected":false},"excerpt":{"rendered":"<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? System.Configuration classes, like most (all?) other classes in Microsoft&#8217;s .Net library documentation, are annotated with the following thread-safety information: Any public static (Shared in Visual Basic) [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4359","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4359","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=4359"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4359\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=4359"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=4359"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=4359"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}