15

Below is a simplified version of where I am trying to set Thread.CurrentPrincipal within an async method to a custom UserPrincipal object but the custom object is getting lost after leaving the await even though it's still on the new threadID 10.

Is there a way to change Thread.CurrentPrincipal within an await and use it later without passing it in or returning it? Or is this not safe and should never be async? I know there are thread changes but thought async/await would handle synching this for me.

[TestMethod]
public async Task AsyncTest()
{
    var principalType = Thread.CurrentPrincipal.GetType().Name;
    // principalType = WindowsPrincipal
    // Thread.CurrentThread.ManagedThreadId = 11

    await Task.Run(() =>
    {
        // Tried putting await Task.Yield() here but didn't help

        Thread.CurrentPrincipal = new UserPrincipal(Thread.CurrentPrincipal.Identity);
        principalType = Thread.CurrentPrincipal.GetType().Name;
        // principalType = UserPrincipal
        // Thread.CurrentThread.ManagedThreadId = 10
    });
    principalType = Thread.CurrentPrincipal.GetType().Name;
    // principalType = WindowsPrincipal (WHY??)
    // Thread.CurrentThread.ManagedThreadId = 10
}
Sean Merron
  • 402
  • 4
  • 14
  • 2
    Are you working with ASP.NET, if so you may want to switch to `HttpContext.Current.User`, that gives you the behavior you are looking for. – Scott Chamberlain Jul 10 '15 at 17:21
  • Hehe, I thought this would come up and should have specified that this has to work for non-web apps where HttpContext is not available. – Sean Merron Jul 10 '15 at 17:48
  • 1
    I did not think you where (You very rarely want to do `Task.Run` in a web app). – Scott Chamberlain Jul 10 '15 at 17:57
  • Yeah and if I refactor out the Task.Run logic into SomeAsyncMethod and then just await SomeAsyncMethod, the same result appears where Thread.CurrentPrincipal is still a WindowsPrincipal after the await instead of a UserPrincipal. – Sean Merron Jul 10 '15 at 18:05

4 Answers4

14

I know there are thread changes but thought async/await would handle synching this for me.

async/await doesn't do any syncing of thread-local data by itself. It does have a "hook" of sorts, though, if you want to do your own syncing.

By default, when you await a task, it will capture the curent "context" (which is SynchronizationContext.Current, unless it is null, in which case it is TaskScheduler.Current). When the async method resumes, it will resume in that context.

So, if you want to define a "context", you can do so by defining your own SynchronizationContext. This is a not exactly easy, though. Especially if your app needs to run on ASP.NET, which requires its own AspNetSynchronizationContext (and they can't be nested or anything - you only get one). ASP.NET uses its SynchronizationContext to set Thread.CurrentPrincipal.

However, note that there's a definite movement away from SynchronizationContext. ASP.NET vNext does not have one. OWIN never did (AFAIK). Self-hosted SignalR doesn't either. It's generally considered more appropriate to pass the value some way - whether this is explicit to the method, or injected into a member variable of the type containing this method.

If you really don't want to pass the value, then there's another approach you can take as well: an async-equivalent of ThreadLocal. The core idea is to store immutable values in a LogicalCallContext, which is appropriately inherited by asynchronous methods. I cover this "AsyncLocal" on my blog (there are rumors of AsyncLocal coming possibly in .NET 4.6, but until then you have to roll your own). Note that you can't read Thread.CurrentPrincipal using the AsyncLocal technique; you'd have to change all your code to use something like MyAsyncValues.CurrentPrincipal.

Stephen Cleary
  • 376,315
  • 69
  • 600
  • 728
  • 2
    `AsyncLocal` in 4.6 is not a rumor, [it's there](https://msdn.microsoft.com/en-us/library/dn906268(v=vs.110).aspx) with no warning that this feature may be removed before release. – Scott Chamberlain Jul 10 '15 at 18:18
  • Thank you for your quick reply Stephen! I was hoping this would get your attention :-) Is this true when dealing with objects in a particular circumstance or just a special case for Thread.CurrentPrincipal? For instance, I can have an Animal that is of the subtype Cat and within an awaited Task change it to a subtype Dog and it is still a Dog after the await. – Sean Merron Jul 10 '15 at 18:22
  • @SeanMerron: It's true for all thread-local variables (where each thread has its own independent value). If your variable is plain static (one value shared between all threads) or local, then there's no problem. – Stephen Cleary Jul 10 '15 at 18:23
  • @SeanMerron Since you were initially in the ThreadPool before awaiting Task.Run, it will continue synchronously in the same thread, so your ThreadLocal static variable will still be set. But Thread.CurrentThread is stored in the ExecutionContext which is handled differently, see my answer for more details. – Jeff Cyr Jul 10 '15 at 20:55
  • 1
    @StephenCleary Great article about AsyncLocal, but I think it would not work for his scenario. The LogicalCallContext will flow one way from the caller to the callee, if the callee add or change a value it won't flow back to the caller right? – Jeff Cyr Jul 10 '15 at 21:04
  • 1
    @JeffCyr: That is correct. Async locals only flow from caller to callee, so the op would have to set the value before the call. – Stephen Cleary Jul 11 '15 at 00:29
  • So if he has to set `Thread.CurrentPrincipal` before the call, it will be flowed as a part of `ExecutionContext` anyway into the `Task.Run` lambda and there'd be no need for `AsyncLocal`, AFAIU. – noseratio Jul 11 '15 at 10:25
  • 1
    @Noseratio: Good point; in this scenario, `AsyncLocal` wouldn't provide any benefit over what `CurrentPrincipal` already does. – Stephen Cleary Jul 11 '15 at 12:23
9

The Thread.CurrentPrincipal is stored in the ExecutionContext which is stored in the Thread Local Storage.

When executing a delegate on another thread (with Task.Run or ThreadPool.QueueWorkItem) the ExecutionContext is captured from the current thread and the delegate is wrapped in ExecutionContext.Run. So if you set the CurrentPrincipal before calling Task.Run, it would still be set inside the Delegate.

Now your problem is that you change the CurrentPrincipal inside Task.Run and the ExecutionContext is only flowed one way. I think this is the expected behavior in most case, a solution would be to set the CurrentPrincipal at the start.

What you originally want is not possible when changing the ExecutionContext inside a Task, because Task.ContinueWith capture the ExecutionContext too. To do it you would have to capture somehow the ExecutionContext right after the Delegate is ran and then flowing it back in a custom awaiter's continuation, but that would be very evil.

Jeff Cyr
  • 4,586
  • 1
  • 24
  • 40
8

You could use a custom awaiter to flow CurrentPrincipal (or any thread properties, for that matter). The below example shows how it might be done, inspired by Stephen Toub's CultureAwaiter. It uses TaskAwaiter internally, so synchronization context (if any) will be captured, too.

Usage:

Console.WriteLine(Thread.CurrentPrincipal.GetType().Name);

await TaskExt.RunAndFlowPrincipal(() => 
{
    Thread.CurrentPrincipal = new UserPrincipal(Thread.CurrentPrincipal.Identity);
    Console.WriteLine(Thread.CurrentPrincipal.GetType().Name);
    return 42;
});

Console.WriteLine(Thread.CurrentPrincipal.GetType().Name);

Code (only very slightly tested):

public static class TaskExt
{
    // flowing Thread.CurrentPrincipal
    public static FlowingAwaitable<TResult, IPrincipal> RunAndFlowPrincipal<TResult>(
        Func<TResult> func,
        CancellationToken token = default(CancellationToken))
    {
        return RunAndFlow(
            func,
            () => Thread.CurrentPrincipal, 
            s => Thread.CurrentPrincipal = s,
            token);
    }

    // flowing anything
    public static FlowingAwaitable<TResult, TState> RunAndFlow<TResult, TState>(
        Func<TResult> func,
        Func<TState> saveState, 
        Action<TState> restoreState,
        CancellationToken token = default(CancellationToken))
    {
        // wrap func with func2 to capture and propagate exceptions
        Func<Tuple<Func<TResult>, TState>> func2 = () =>
        {
            Func<TResult> getResult;
            try
            {
                var result = func();
                getResult = () => result;
            }
            catch (Exception ex)
            {
                // capture the exception
                var edi = ExceptionDispatchInfo.Capture(ex);
                getResult = () => 
                {
                    // re-throw the captured exception 
                    edi.Throw(); 
                    // should never be reaching this point, 
                    // but without it the compiler whats us to 
                    // return a dummy TResult value here
                    throw new AggregateException(edi.SourceException);
                }; 
            }
            return new Tuple<Func<TResult>, TState>(getResult, saveState());    
        };

        return new FlowingAwaitable<TResult, TState>(
            Task.Run(func2, token), 
            restoreState);
    }

    public class FlowingAwaitable<TResult, TState> :
        ICriticalNotifyCompletion
    {
        readonly TaskAwaiter<Tuple<Func<TResult>, TState>> _awaiter;
        readonly Action<TState> _restoreState;

        public FlowingAwaitable(
            Task<Tuple<Func<TResult>, TState>> task, 
            Action<TState> restoreState)
        {
            _awaiter = task.GetAwaiter();
            _restoreState = restoreState;
        }

        public FlowingAwaitable<TResult, TState> GetAwaiter()
        {
            return this;
        }

        public bool IsCompleted
        {
            get { return _awaiter.IsCompleted; }
        }

        public TResult GetResult()
        {
            var result = _awaiter.GetResult();
            _restoreState(result.Item2);
            return result.Item1();
        }

        public void OnCompleted(Action continuation)
        {
            _awaiter.OnCompleted(continuation);
        }

        public void UnsafeOnCompleted(Action continuation)
        {
            _awaiter.UnsafeOnCompleted(continuation);
        }
    }
}
noseratio
  • 56,401
  • 21
  • 172
  • 421
  • 1
    I think this is the best chance to make this work so I'll see what I can do with it. Thanks for taking the time to put this together! – Sean Merron Jul 13 '15 at 11:16
6

ExecutionContext, which contains SecurityContext, which contains CurrentPrincipal, is pretty-much always flowed across all asynchronous forks. So in your Task.Run() delegate, you - on a separate thread as you note, get the same CurrentPrincipal. However, under the hood, you get the context flowed via ExecutionContext.Run(...), which states:

The execution context is returned to its previous state when the method completes.

I find myself in strange territory differing with Stephen Cleary :), but I don't see how SynchronizationContext has anything to do with this.

Stephen Toub covers most of this in an excellent article here.

sellotape
  • 7,229
  • 2
  • 24
  • 25
  • I agree. A custom `SynchronizationContext` wouldn't help because `CurrentPrincipal` would be restored by the time `SynchronizationContext.Post` is called as a part of `await` continuation. A [custom awaiter](http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115642.aspx) might be an option, but there's always a possible race condition that the task completes before the awaiter's `ICriticalNotifyCompletion.OnCompleted` is called. – noseratio Jul 11 '15 at 10:32
  • Great article! Thanks sellotape! – Sean Merron Jul 13 '15 at 11:12