Does the thread identity get transferred when using PLINQ Extensions?

后端 未结 3 1485
伪装坚强ぢ
伪装坚强ぢ 2021-02-15 13:51

I am using .AsParallel().ForAll() to enumerate a collection in parallel in the context of an ASP.NET request. The enumeration method relies on System.Threading.Thread.CurrentPr

相关标签:
3条回答
  • 2021-02-15 14:22

    One subtle thing to notice when passing Principal through .AsParallel() boundary: Where your sequence gets materialized?

    This isn't a problem with .ForAll(), but consider another scenario:

    var result = items.AsParallel().Select(MyTransform);
    

    Then you're passing result elsewhere so that it crosses thread boundary (which is likely, say, if you're returning it out of WCF action method).

    In this case by the time MyTransform gets applied, Thread.CurrentPrincipal value might contain something unexpected.

    So, the workaround here is to materialize query on the spot (by calling .ToArray(), .ToList(), etc.)

    0 讨论(0)
  • 2021-02-15 14:25

    This is the implementation behind CurrentPrincipal

    public static IPrincipal CurrentPrincipal
    {
        get
        {
            lock (CurrentThread)
            {
                IPrincipal threadPrincipal = CallContext.Principal;
                if (threadPrincipal == null)
                {
                    threadPrincipal = GetDomain().GetThreadPrincipal();
                    CallContext.Principal = threadPrincipal;
                }
                return threadPrincipal;
            }
        }
        set { CallContext.Principal = value; }
    }
    

    All newly created threads will have null and it will be taken from application domain. So it should be ok. Nevertheless you need be careful with culture. It will not be derived from starting thread. See: Parallel Programing, PLINQ and Globalization

    0 讨论(0)
  • 2021-02-15 14:39

    No, the identity will not be propagated to these worker threads automatically. If, in fact, the components you are using are HttpContext.User what you can do is capture the current, "ambient" HttpContext instance in your "main" thread and propagate it to your worker threads. That would look something like this:

    HttpContext currentHttpContext = HttpContext.Current;
    
    myWorkItems.AsParallel().ForAll(wi =>
    { 
        HttpContext.Current = currentHttpContext;
    
        try
        {
            // anything called from here out will find/use the context of your original ASP.NET thread
        }
        finally
        {
           // Disassociate the context from the worker thread so that it is not held on to beyond its official lifetime
           HttpContext.Current = null;
        }
    });
    

    This works because HttpContext.Current is backed by a thread static, so every worker thread will be assigned the instance from your main thread and any work done on it from that point will see that as the current instance.

    Now, you have to be aware that HttpContext and its related classes were not designed to be thread safe, so this is a bit of a hack. If you're only reading from properties this isn't really a problem. If you are not using components that rely on HttpContext.Current then it would be "cleaner" to not set that and instead just use the captured currentHttpContext variable directly in the worker.

    Finally, if all you really need is to propagate the current principal to the worker threads then you can do just that instead using the same approach:

    Principal logicalPrincipal = Thread.CurrentPrincipal;
    
    myWorkItems.AsParallel().ForAll(wi =>
    { 
        Principal originalWorkerThreadPrincipal = Thread.CurrentPrincipal;
        Thread.CurrentPrincipal = logicalPrincipal;
    
        try
        {
            // anything called from here out will find the principal from your original thread
        }
        finally
        {
           // Revert to the original identity when work is complete
           Thread.CurrentPrincipal = originalWorkerThreadPrincipal;
        }
    });
    
    0 讨论(0)
提交回复
热议问题