{"id":56067,"date":"2010-10-21T13:25:00","date_gmt":"2010-10-21T13:25:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/pfxteam\/2010\/10\/21\/new-feature-threadlocalt-values\/"},"modified":"2010-10-21T13:25:00","modified_gmt":"2010-10-21T13:25:00","slug":"new-feature-threadlocalt-values","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/new-feature-threadlocalt-values\/","title":{"rendered":"New Feature? :: ThreadLocal.Values"},"content":{"rendered":"

We’ve been considering adding a Values property to\nSystem.Threading.ThreadLocal<T>.  Values\nwould return a collection of all current values from all threads (e.g. what\nyou’d get if you evaluated Value from each thread).  This would allow for easy aggregations, and\nin fact in our Parallel Extensions Extras we have a wrapper around\nThreadLocal<T> called ReducationVariable<\/a><T>\nthat exists purely to provide this functionality.  For example:<\/p>\n

 <\/p>\n

var localResult = new ThreadLocal<int>(() => 0);
Parallel.For(0, N, i =>
{
    localResult.Value\n+= Compute(i);
});<\/span><\/p>\n

int result = localResult.Values.Sum();<\/span><\/p>\n


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

If you’re familiar with the Parallel Patterns Library (PPL)\nin Visual C++ 2010, this feature would make ThreadLocal<T> very similar in\ncapability to the combinable class<\/a>.<\/p>\n

 <\/p>\n

In .NET 4, it’s already possible to do aggregations using\nthe thread-local data support that’s built in to the parallel loops.<\/p>\n

 <\/p>\n

Parallel.For(0,\nN,
    () => 0,
    (i, loopState, localResult) =>
    {
        return localResult\n+ Compute(i);
    },
    localResult => Interlocked.Add(ref result, localResult));<\/span><\/p>\n


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

This approach of using Parallel.For has less overhead than\naccessing the ThreadLocal<T> instance on each iteration, which is one of\nthe reasons Parallel.For has the support built-in.  However, there are some advantages to also\nhaving the ThreadLocal<T> approach available:<\/p>\n

    \n
  1. Fewer\ndelegates to understand<\/strong>.  Wrapping\nyour head around three different delegates (and how data is passed between\nthem) in a single method call can be tough. \nIt may also be unintuitive that an interlocked operation is required for\nthe final step (though this approach has performance benefits, as each thread\ngets to perform its final reduction in parallel).<\/li>\n
  2. Certain\nscenarios may enjoy less overhead<\/strong>.  <\/strong>There is potentially a subtle performance\nissue with the Parallel.For approach, depending on why the local support is\nbeing used.  In an effort to be fair to\nother users of the ThreadPool, the Tasks that service a parallel loop will\nperiodically (every few hundred milliseconds) retire and reschedule replicas of\nthemselves.  In this way, the threads\nthat were processing the loop’s tasks get a breather to optionally process work\nin other AppDomains if the ThreadPool deems it necessary.  The ThreadPool may also choose to remove the\nthread from active duty if it believes the active thread count is too high. Consequently,\nthe number of Tasks created to service the loop may be greater than the number\nof threads.  In turn, the delegates that\ninitialize and finalize\/aggregate the local states will be executed more,\nbecause they are run for each new Task rather than each new Thread.  Of course, this would only be an issue if the\ninitializer and finalizer delegates are very expensive, but it’s worth noting\nthat the ThreadLocal<T> approach does not suffer from this.<\/li>\n
  3. Usable in\nplaces where built-in local support isn’t available<\/strong>.  You can do aggregations where we do not have\nbuilt-in thread-local data support.  For\nexample, Parallel.Invoke does not provide local support.<\/li>\n<\/ol>\n

    \n

    \n

    Your input could help! \nIf you’ve got a minute, feel free to answer the following questions\nand\/or provide other thoughts:<\/p>\n

      \n
    1. Would you find writing aggregations easier with\nThreadLocal<T>.Values compared to using the support built in to the\nparallel loops?  If so, does the\nconvenience make the feature worthwhile?<\/li>\n
    2. Do you need\/want support for writing\naggregations outside of parallel loops?<\/li>\n
    3. When you do aggregations, are the routines for\ninitializing and finalizing local state expensive?  Examples would be great.<\/li>\n<\/ol>\n

      \n

      \n

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

      We’ve been considering adding a Values property to System.Threading.ThreadLocal<T>.  Values would return a collection of all current values from all threads (e.g. what you’d get if you evaluated Value from each thread).  This would allow for easy aggregations, and in fact in our Parallel Extensions Extras we have a wrapper around ThreadLocal<T> called ReducationVariable<T> that […]<\/p>\n","protected":false},"author":485,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7908],"tags":[7916,7921,7927,7909,7912],"class_list":["post-56067","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pfxteam","tag-coordination-data-structures","tag-feedback-requested","tag-new-feature","tag-parallel-extensions","tag-task-parallel-library"],"acf":[],"blog_post_summary":"

      We’ve been considering adding a Values property to System.Threading.ThreadLocal<T>.  Values would return a collection of all current values from all threads (e.g. what you’d get if you evaluated Value from each thread).  This would allow for easy aggregations, and in fact in our Parallel Extensions Extras we have a wrapper around ThreadLocal<T> called ReducationVariable<T> that […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/56067","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\/485"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=56067"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/56067\/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=56067"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=56067"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=56067"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}