Festlegen von Thread.CurrentPrincipal mit async/await

Question

Unten ist eine vereinfachte Version von wo ich Thread.CurrentPrincipal innerhalb einer asynchronen Methode auf ein benutzerdefiniertes UserPrincipal -Objekt festlegen möchte, aber das benutzerdefinierte Objekt verloren geht, nachdem die Wartezeit verlassen, obwohl es noch ist auf der neuen threadID 10.

Gibt es eine Möglichkeit, Thread.CurrentPrincipal innerhalb eines Wartens zu ändern und später zu verwenden, ohne es weiterzugeben oder zurückzugeben? Oder ist das nicht sicher und sollte niemals asynchron sein? Ich weiß, es gibt Thread-Änderungen, aber dachte async/erwarten würde synching dies für mich behandeln.

[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 
} 

Answer 1

Sie könnten einen benutzerdefinierten Warner verwenden, um CurrentPrincipal (oder beliebige Thread-Eigenschaften, für die Angelegenheit) zu fließen. Das folgende Beispiel zeigt, wie es gemacht werden könnte, inspiriert von Stephen Toub's CultureAwaiter. Es verwendet TaskAwaiter intern, sodass auch der Synchronisationskontext (falls vorhanden) erfasst wird.

Verbrauch:

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 (nur sehr wenig getestet):

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

Answer 2

Ich weiß, es gibt Änderungen Thread aber dachte async/await würde synching dies für mich behandeln.

async/await führt keine Synchronisierung von faden lokalen Daten von selbst aus. Es hat jedoch einen "Haken", wenn Sie Ihre eigene Synchronisierung durchführen möchten.

standardmäßig, wenn Sie await eine Aufgabe, wird es den curent „Kontext“ erfassen (die SynchronizationContext.Current ist, es sei denn, es null ist, in welchem ​​Fall es TaskScheduler.Current). Wenn die Methode async fortgesetzt wird, wird sie in diesem Kontext fortgesetzt.

Also, wenn Sie einen "Kontext" definieren möchten, können Sie dies tun, indem Sie Ihre eigene SynchronizationContext definieren. Dies ist jedoch nicht gerade einfach. Vor allem, wenn Ihre App auf ASP.NET ausgeführt werden muss, was eine eigene AspNetSynchronizationContext erfordert (und sie können nicht geschachtelt werden oder irgendetwas - Sie erhalten nur einen). ASP.NET verwendet SynchronizationContext, um Thread.CurrentPrincipal festzulegen.

Beachten Sie jedoch, dass es eine eindeutige Bewegung entfernt von SynchronizationContext gibt. ASP.NET vNext hat keinen. OWIN hat es nie getan (AFAIK). Self-Hosted SignalR tut auch nicht. Es wird allgemein als geeigneter erachtet, den Wert irgendeinen Weg zu übergeben - ob dies für die Methode explizit ist oder in eine Elementvariable des Typs, der diese Methode enthält, eingefügt wird.

Wenn Sie wirklich wollen nicht den Wert zu übergeben, dann gibt es einen anderen Ansatz, den Sie auch nehmen kann: ein async -Äquivalent von ThreadLocal. Die Kernidee besteht darin, unveränderliche Werte in einer LogicalCallContext zu speichern, die in geeigneter Weise durch asynchrone Methoden vererbt wird. Ich verdecke diese "AsyncLocal" auf meinem Blog (es gibt Gerüchte von AsyncLocal kommen möglicherweise in .NET 4.6, aber bis dahin müssen Sie Ihre eigenen rollen). Beachten Sie, dass Sie die mit der AsyncLocal Technik nicht lesen können; Sie müssten Ihren gesamten Code ändern, um etwas wie MyAsyncValues.CurrentPrincipal zu verwenden.

Answer 3

Der Thread.CurrentPrincipal wird im ExecutionContext gespeichert, der im lokalen Threadspeicher gespeichert wird.

Beim Ausführen eines Delegaten in einem anderen Thread (mit Task.Run oder ThreadPool.QueueWorkItem) wird der ExecutionContext aus dem aktuellen Thread erfasst und der Delegat wird in ExecutionContext.Run eingewickelt. Wenn Sie also das CurrentPrincipal vor dem Aufruf von Task.Run setzen, wird es immer noch im Delegate festgelegt.

Jetzt ist Ihr Problem, dass Sie das CurrentPrincipal in Task.Run ändern und der ExecutionContext wird nur in eine Richtung fließen. Ich denke, dies ist das erwartete Verhalten in den meisten Fällen, eine Lösung wäre, das CurrentPrincipal am Anfang zu setzen.

Was ursprünglich gewünscht ist, ist nicht möglich, wenn Sie den ExecutionContext in einer Task ändern, da Task.ContinueWith auch den ExecutionContext erfasst. Um das zu tun, müßten Sie den ExecutionContext direkt nach dem Ausführen des Delegates einfangen und dann in einer Fortsetzung des Custom Waiters weiterleiten, aber das wäre sehr böse.

Answer 4

ExecutionContext, die enthält SecurityContext, die CurrentPrincipal enthält, ist ziemlich viel über alle asynchronen Gabeln geflossen. Also in Ihrem Task.Run() Delegierten, erhalten Sie - in einem separaten Thread, wie Sie bemerken, erhalten Sie CurrentPrincipal. Doch unter der Haube, erhalten Sie das Kontext floss über ExecutionContext.Run(...), in dem es heißt:

Der Ausführungskontext in den vorherigen Zustand zurückgeführt, wenn die Verfahren abgeschlossen ist.

Ich finde mich in seltsames Territorium, das sich mit Stephen Cleary unterscheidet :), aber ich sehe nicht, wie SynchronizationContext irgendetwas damit zu tun hat.

Stephen Toub deckt das meiste davon in einem ausgezeichneten Artikel here ab.