target<\/em>. <\/p>\nIn Beta 1, we thought we\u2019d be really smart by disposing of the objects that were created by threads that lost the race, if they implemented IDisposable. Turns out that\u2019s a pretty bad thing to do. With lazy initialization, we assumed that most of time valueFactory would be creating a new value but that isn\u2019t always the case. It\u2019s quite possible that a valueFactory could return an object that has already been created, in which case, we\u2019d be disposing of an object we didn\u2019t own. <\/p>\n
We\u2019re making a couple of changes in the Parallel Extensions to ensure that we generally don\u2019t dispose of object we aren\u2019t sure we own and, moving forward, any new APIs that do eagerly instantiate objects that might not be used will not dispose of said objects. <\/p>\n
Now you might say, \u201cwhy? Ninety-percent of the time I am<\/em> creating a new object with my value factory and it might be a really heavy object like a file or wait handle!\u201d We hear you, but typically, once an object is disposed, there is no bringing it back and so by disposing of these objects we don\u2019t allow anyone to opt out of that behavior if need be. If we don\u2019t dispose, the GC will still cleanup your unused objects and if you really need to dispose of an object manually, there is a work around, i.e.<\/p>\nManualResetEvent theEvent = null<\/span>;\nManualResetEvent tmpEvent;\nLazyInitializer.EnsureInitialized(ref<\/span> theEvent, \n () => { return<\/span> tmpEvent = new<\/span> ManualResetEvent(false<\/span>); });\nif<\/span> (tmpEvent != theEvent) tmpEvent.Close();<\/pre>\nIn fact, you could easily create a small wrapper function to do the work for you, i.e.<\/p>\n
public<\/span> static<\/span> T EnsureInitializedWithDispose<T>(ref<\/span> T target, Func<T> function) \n where<\/span> T : class<\/span>, IDisposable\n{\n T tmp = default<\/span>(T);\n T actual = LazyInitializer.EnsureInitialized(ref<\/span> target, () => tmp = function());\n if<\/span> (actual != tmp) ((IDisposable)tmp).Dispose();\n return<\/span> actual;\n}<\/pre>\n.csharpcode, .csharpcode pre\n{\n\tfont-size: small;\n\tcolor: black;\n\tfont-family: consolas, “Courier New”, courier, monospace;\n\tbackground-color: #ffffff;\n\t\/*white-space: pre;*\/\n}\n.csharpcode pre { margin: 0em; }\n.csharpcode .rem { color: #008000; }\n.csharpcode .kwrd { color: #0000ff; }\n.csharpcode .str { color: #006080; }\n.csharpcode .op { color: #0000c0; }\n.csharpcode .preproc { color: #cc6633; }\n.csharpcode .asp { background-color: #ffff00; }\n.csharpcode .html { color: #800000; }\n.csharpcode .attr { color: #ff0000; }\n.csharpcode .alt \n{\n\tbackground-color: #f4f4f4;\n\twidth: 100%;\n\tmargin: 0em;\n}\n.csharpcode .lnum { color: #606060; }<\/p>\n
And the issue isn\u2019t just about race conditions. In general, we should never dispose of an object we didn\u2019t explicitly create. BlockingCollection<T> in Beta 1, for example, will dispose of it\u2019s underlying collection if the BlockingCollection<T> itself is disposed. Again, this is bad news if you only were using the BlockingCollection<T> as a temporary wrapper. In future releases of Visual Studio 2010, this will be corrected. <\/p>\n
So when using these APIs, and any other API that may consume or create an IDisposable object, think about what that API is doing with the object and if you need to clean up resources manually. If you\u2019re not sure, the finalizer should take care of most of your problems. In the rare situations where immediate cleanup is important, make sure you keep track of the objects and dispose of them properly. Also, when designing your own libraries, don\u2019t dispose of objects you don\u2019t own!\n.csharpcode, .csharpcode pre\n{\n\tfont-size: small;\n\tcolor: black;\n\tfont-family: consolas, “Courier New”, courier, monospace;\n\tbackground-color: #ffffff;\n\t\/*white-space: pre;*\/\n}\n.csharpcode pre { margin: 0em; }\n.csharpcode .rem { color: #008000; }\n.csharpcode .kwrd { color: #0000ff; }\n.csharpcode .str { color: #006080; }\n.csharpcode .op { color: #0000c0; }\n.csharpcode .preproc { color: #cc6633; }\n.csharpcode .asp { background-color: #ffff00; }\n.csharpcode .html { color: #800000; }\n.csharpcode .attr { color: #ff0000; }\n.csharpcode .alt \n{\n\tbackground-color: #f4f4f4;\n\twidth: 100%;\n\tmargin: 0em;\n}\n.csharpcode .lnum { color: #606060; }<\/p>\n","protected":false},"excerpt":{"rendered":"
In concurrent programs, race conditions are a fact of life but they aren\u2019t all bad. Sometimes, race conditions are benign, as is often the case with lazy initialization. The problem with racing to set a value, however, is that it can result in multiple objects being instantiated when only one is needed. Take the LazyInitializer […]<\/p>\n","protected":false},"author":486,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7908],"tags":[],"class_list":["post-55988","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pfxteam"],"acf":[],"blog_post_summary":"
In concurrent programs, race conditions are a fact of life but they aren\u2019t all bad. Sometimes, race conditions are benign, as is often the case with lazy initialization. The problem with racing to set a value, however, is that it can result in multiple objects being instantiated when only one is needed. Take the LazyInitializer […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/55988","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/486"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=55988"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/55988\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=55988"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=55988"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=55988"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}