{"id":1793,"date":"2009-05-18T16:34:00","date_gmt":"2009-05-18T16:34:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2009\/05\/18\/the-conditional-weak-table-enabling-dynamic-object-properties\/"},"modified":"2021-10-04T15:43:59","modified_gmt":"2021-10-04T22:43:59","slug":"the-conditional-weak-table-enabling-dynamic-object-properties","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/the-conditional-weak-table-enabling-dynamic-object-properties\/","title":{"rendered":"The Conditional Weak Table: Enabling Dynamic Object Properties"},"content":{"rendered":"

The Dynamic Language Runtime allows you to implement a dynamic language (such as Ruby or Python) on top of the CLR. There are a lot of challenges to making everything work right. One particularly difficult aspect was enabling Ruby to attach arbitrary “properties” to instanced .NET managed objects at runtime. <\/font><\/span><\/p>\n

If a Ruby developer sets an instance variable on a Ruby object everything can be handled by the Ruby compiler. But the Dynamic Language Runtime (DLR) offers the ability to use .NET types in your dynamic language. When a Ruby developer sets instance variables on .NET objects the objects are stored as keys in an internal table and the instance variables are stored as values.<\/font><\/span><\/p>\n

For the first release, the DLR used a weak hashtable implementation to store keys and values. But in CLR v4, we did an interesting feature for the benefit of language compiler authors: the Conditional Weak Table<\/strong>. You can find the class <\/font><\/span>ConditionalWeakTable<TKey, TValue><\/span> in the System.Runtime. CompilerServices namespace. It’s in CompilerServices because it’s not a general-purpose dictionary type: we intend for it to only be used by compiler writers.<\/span><\/p>\n

<\/span><\/font><\/font><\/p>\n

The reason we needed to expose a new class in the runtime is that in some scenarios the keys and values can be pointing at each other. This causes problems in a weak hashtable because the GC can never free memory that is still referenced. Consider the following Ruby code, which sets instance variables (x and y) on a .NET object<\/font><\/span><\/p>\n

# Allow Ruby to access .NET types<\/p>\n

<\/span><\/p>\n

require ‘mscorlib’<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

module System<\/p>\n

<\/span><\/p>\n

  <\/span>module Exception # Reopening CLR’s System.Exception<\/p>\n

<\/span><\/p>\n

    <\/span>#This is equivalent to defining properties x and y in c#<\/p>\n

<\/span><\/p>\n

    <\/span>def x<\/p>\n

<\/span><\/p>\n

      <\/span>@x<\/p>\n

<\/span><\/p>\n

    <\/span>end<\/p>\n

<\/span><\/p>\n

    <\/span>def x=(val)<\/p>\n

<\/span><\/p>\n

      <\/span>@x=val<\/p>\n

<\/span><\/p>\n

    <\/span>end<\/p>\n

<\/span><\/p>\n

    <\/span>def y<\/p>\n

<\/span><\/p>\n

      <\/span>@y<\/p>\n

<\/span><\/p>\n

    <\/span>end<\/p>\n

<\/span><\/p>\n

    <\/span>def y=<\/p>\n

<\/span><\/p>\n

      <\/span>@y=val<\/p>\n

<\/span><\/p>\n

    <\/span>end<\/p>\n

<\/span><\/p>\n

  <\/span>end<\/p>\n

<\/span><\/p>\n

end<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

e1 = System::Exception.new<\/p>\n

<\/span><\/p>\n

e2 = System::Exception.new<\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/p>\n

<\/span><\/p>\n

# This causes a circular reference: <\/p>\n

<\/span><\/p>\n

# e1.x points to e2 (and e2.y), and e2.y points to e1 (and e1.x)<\/p>\n

<\/span><\/p>\n

e1.x = e2<\/p>\n

<\/span><\/p>\n

e2.y = e1<\/p>\n

<\/span><\/p>\n

The instance variables in this example create a circular reference between the keys and values. <\/span>This is an issue in practice; hence the request for a CLR provided solution. Leaking a little memory doesn’t affect the correctness of the program, but it definitely isn’t an ideal situation.<\/span><\/p>\n

<\/span><\/font><\/font><\/p>\n

You might be wondering how <\/font><\/span>ConditionalWeakTable<TKey, TValue> <\/span>is different from the<\/font><\/span> <\/span>Dictionary<TKey,TValue> <\/span>class.<\/font><\/span><\/p>\n

Unlike a <\/font><\/span>Dictionary<TKey,TValue>,<\/span> the keys in the weak table are weak references and the values  <\/span>are kept alive only if the corresponding object key is alive. This means that a key whose value has no references outside the conditional weak table is considered dead and the dictionary automatically removes the key\/value entry after GC happens.<\/font><\/span><\/p>\n

 <\/span>Also unlike <\/font><\/font><\/span>Dictionary<TKey,TValue>,<\/span> the weak table’s methods are thread-safe and requires no additional locking to be done by callers. <\/span><\/font><\/font><\/p>\n

As stated in the beginning, the conditional weak table is not intended to be a general purpose collection. It does not expose the full public surface area of IDictionary. For example, it’s not possible to enumerate over the conditional weak table. If you need dictionary-like functionality in your code you should use the <\/font><\/span>Dictionary<<\/span>TKey,TValue<\/span>><\/span> from the System.Collections.Generics namespace. But if you’re writing a .NET language of your own and need to expose the ability to attach properties to objects you should definitely look into the Conditional Weak Table.<\/font><\/span><\/p>\n

<\/font><\/span> <\/p>\n

Diana Milirud,<\/font><\/span><\/p>\n

SDET, CLR<\/font><\/span><\/p>\n

<\/font><\/span> <\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

The Dynamic Language Runtime allows you to implement a dynamic language (such as Ruby or Python) on top of the CLR. There are a lot of challenges to making everything work right. One particularly difficult aspect was enabling Ruby to attach arbitrary “properties” to instanced .NET managed objects at runtime. If a Ruby developer sets […]<\/p>\n","protected":false},"author":342,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685],"tags":[],"class_list":["post-1793","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet"],"acf":[],"blog_post_summary":"

The Dynamic Language Runtime allows you to implement a dynamic language (such as Ruby or Python) on top of the CLR. There are a lot of challenges to making everything work right. One particularly difficult aspect was enabling Ruby to attach arbitrary “properties” to instanced .NET managed objects at runtime. If a Ruby developer sets […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/1793","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\/342"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=1793"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/1793\/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=1793"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=1793"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=1793"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}