Does the thread identity get transferred when using PLINQ Extensions?

Question

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.CurrentPrincipal.

Can I rely on the individual threads used to have their System.Threading.Thread.CurrentPrincipal set to the HttpContext.Current.User of the thread that is processing the ASP.NET Request or do I need to manage that myself?

Another way of asking the question is do the threads used by PLINQ inherit the identity of the thread that invoked the operation?

Answer 1

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;
    }
});

Answer 2

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

Answer 3

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.)