Holen Sie sich SynchronizationContext aus einem bestimmten Thread

Ist dies nicht möglich. Das problem ist, dass SynchronizationContext und ein Thread sind wirklich zwei vollkommen verschiedene Konzepte.

Während es wahr ist, dass die Windows Forms-und WPF-setup ein SynchronizationContext für den Haupt-thread, die meisten anderen threads nicht. Zum Beispiel, keiner der threads im ThreadPool enthalten Ihre eigenen SynchronizationContext (es sei denn, natürlich, Sie installieren Ihre eigenen).

Es ist auch möglich, für eine SynchronizationContext werden völlig unabhängig von threads und threading. Eine Synchronisierung der Rahmen kann leicht eingerichtet werden, die synchronisiert auf einen externen Dienst oder einen gesamten thread-pool, etc.

In deinem Fall, würde ich empfehlen die Einstellung Ihres UIConfiguration.SynchronizationContext innerhalb der ersten, Hauptformular Geladen Veranstaltung. Der Rahmen ist garantiert begann an diesem Punkt, und wird unbrauchbar, bis die Meldung Pumpe gestartet wurde, in jedem Fall.

Fand ich, wie die meisten prägnant und hilfreich, um mir die folgenden Passagen aus dem Buch von Alex Davies "Async in C# 5.0. O ' Reilly Verl., 2012", S..48-49:

• "SynchronizationContext ist eine Klasse von der .NET Framework, welche die Möglichkeit hat, code ausführen, der in eine bestimmte Art von Faden.
  
  Es gibt verschiedene Synchronisations-Kontexten verwendet .NET, von denen die wichtigsten sind der UI-thread-Kontexte verwendet, die von WinForms und WPF."

• "Instanzen SynchronizationContext selbst nicht alles tun, sehr nützlich, so dass alle tatsächlichen Instanzen neigen dazu, werden Unterklassen.

  Es hat auch statische Elemente, aus denen Sie Lesen und die Kontrolle der Strom SynchronizationContext.

  Die aktuelle SynchronizationContext ist eine Eigenschaft des aktuellen Threads.

  Die Idee ist, dass an jedem Punkt, dass du immer in einem speziellen thread, Sie sollten in der Lage sein zu Holen Sie sich die aktuellen SynchronizationContext auf und speichern es. Später können Sie es verwenden, um code auszuführen, wieder auf die spezielle Faden, den Sie begonnen. All dies sollte möglich sein,, ohne genau zu wissen, welchen thread Sie begonnen, so lange wie Sie können, verwenden Sie die SynchronizationContext, Sie können Holen Sie sich zurück, um es.

  Die wichtige Methode der SynchronizationContext ist Post können, die eine Stellvertretung führen Sie in den richtigen Kontext zu"
  
  .

• "Einige SynchronizationContexts Kapseln einem einzigen thread, wie den UI-thread.
  
  Einige Kapseln eine bestimmte Art von Faden — zum Beispiel die thread — pool- aber können wählen, eine von diesen threads zu posten der Stellvertretung. Einige nicht wirklich ändern, welcher thread der code läuft auf, sondern Sie sind nur zur überwachung eingesetzt, wie die ASP.NET Synchronisation Kontext"

Komplette und funktionierende extension-methods für getting die SynchronizationContext aus einer Thread oder ExecutionContext (oder null wenn keiner vorhanden ist), oder eine DispatcherSynchronizationContext aus einer Dispatcher. Getestet auf .NET 4.6.2.

using Ectx = ExecutionContext;
using Sctx = SynchronizationContext;
using Dctx = DispatcherSynchronizationContext;

public static class _ext
{
    //DispatcherSynchronizationContext from Dispatcher
    public static Dctx GetSyncCtx(this Dispatcher d) => d?.Thread.GetSyncCtx() as Dctx;

    //SynchronizationContext from Thread
    public static Sctx GetSyncCtx(this Thread th) => th?.ExecutionContext?.GetSyncCtx();

    //SynchronizationContext from ExecutionContext
    public static Sctx GetSyncCtx(this Ectx x) => __get(x);

    /* ... continued below ... */
}

Alle der oben genannten Funktionen am Ende aufrufen der __get code unten gezeigt, die garantiert einige Erklärungen.

Beachten Sie, dass __get ist ein statisches Feld, pre-initialized mit einem entfernbare lambda-block. Dies ermöglicht es uns, ordentlich abfangen der erste Anrufer nur, um die einmalige Initialisierung, das bereitet einem winzigen und dauerhaften Ersatz delegieren, die viel schneller und Reflexion-kostenlos.

Der Letzte Akt für die unerschrockenen Initialisierung Aufwand ist, tauschen Sie den Ersatz in "__get", die gleichzeitig und tragischerweise bedeutet, dass der code verwirft sich selbst, ohne Spuren zu hinterlassen, und alle nachfolgenden Anrufer gehen Sie direkt in die DynamicMethod richtigen, ohne auch nur einen Hauch von bypass-Logik.

static Func<Ectx, Sctx> __get = arg =>
{
    //Hijack the first caller to do initialization...

    var fi = typeof(Ectx).GetField(
        "_syncContext",                         //private field in 'ExecutionContext'
        BindingFlags.NonPublic|BindingFlags.Instance);

    var dm = new DynamicMethod(
        "foo",                                  //(any name)
        typeof(Sctx),                           //getter return type
        new[] { typeof(Ectx) },                 //type of getter's single arg
        typeof(Ectx),                           //"owner" type
        true);                                  //allow private field access

    var il = dm.GetILGenerator();
    il.Emit(OpCodes.Ldarg_0);
    il.Emit(OpCodes.Ldfld, fi);
    il.Emit(OpCodes.Ret);

    //...now replace ourself...
    __get = (Func<Ectx, Sctx>)dm.CreateDelegate(typeof(Func<Ectx, Sctx>));

    //oh yeah, don't forget to handle the first caller's request
    return __get(arg);                 // ...never to come back here again. SAD!
};

Das niedliche Teil ist ganz am Ende, wo--um tatsächlich abrufen des Werts für die vorbelegt ersten Anrufer--die Funktion angeblich nennt sich selbst mit seinem eigenen argument, sondern vermeidet recursing durch den Austausch selbst unmittelbar vor.

Es keinen besonderen Grund für den Nachweis dieser ungewöhnlichen Technik, die auf das spezielle problem der SynchronizationContext unter Diskussion auf dieser Seite. Greifen die _syncContext Feld aus einer ExecutionContext leicht und trivial behandelt mit traditionellen Reflexion (plus einige Erweiterung Methode Zuckerguss). Aber ich dachte, ich Teile diesen Ansatz, die ich habe persönlich für eine Weile jetzt, denn es ist auch leicht angepasst und nur so weit anwendbar auf solche Fälle.

Es ist besonders geeignet, wenn höchste Leistung erforderlich ist, den Zugriff auf den nicht-öffentlichen Bereich. Ich denke, dass ich ursprünglich verwendet, diese in einem QPC-basierte Frequenzzähler, wo das Feld war zu Lesen in einer engen Schleife, die Durchlaufen alle 20 oder 25 Nanosekunden, was nicht wirklich möglich sein, mit herkömmlichen Reflexion.

Damit ist die wichtigste Antwort, aber unten habe ich einige interessante Punkte, weniger relevant für den Fragesteller die Anfrage, außerdem ist die Technik nur demonstriert.

Laufzeit Anrufer

Für Klarheit, trennte ich die "installation swap" und "erste Verwendung" Schritte in zwei separate Zeilen im code oben gezeigt, im Gegensatz zu dem, was ich in meinem eigenen code (die folgende version vermeidet auch eine Haupt-Speicher Holen gegenüber der älteren, die potenziell einbezieht, für die thread-Sicherheit, siehe die detaillierte Diskussion unten):

return (__get = (Func<Ectx, Sctx>)dm.CreateDel...(...))(arg);

In anderen Worten, alle Anrufer, einschließlich der ersten, Hole den Wert, der genau in der gleichen Weise, und keine Reflexion-code überhaupt benutzt wird, dies zu tun. Es schreibt nur der Ersatz getter. Mit freundlicher Genehmigung von il-visualizer, können wir sehen, die Körper der DynamicMethod im debugger zur Laufzeit:

Lock-freien thread-Sicherheit

Sollte ich beachten Sie, dass die ein-und Auslagerung der Hauptteil der Funktion ist eine vollständig thread-sicheren Betrieb gegeben .NET Speicher Modell und die lock-free-Philosophie. Letzteres begünstigt vorwärts-Fortschritt gewährleistet mit den möglichen Kosten zu tun, doppelte oder überflüssige arbeiten. Multi-way-Race) um die Initialisierung ist korrekt, erlaubt eine vollständig fundierte theoretische Grundlage:

• das Rennen Einstiegspunkt (initialization code) ist Global pre-konfiguriert und geschützt (durch die .NET-loader), so dass (mehrere) racers (wenn vorhanden) geben Sie den gleichen Initialisierer, die sich nie gesehen, als null.
• mehrere Rennen Produkten (getter) sind immer logisch identisch, so spielt es keine Rolle, welche einen bestimmten racer (oder später nicht-racing Anrufer) passiert zu Holen, oder auch, ob alle racer landet, über den Sie selbst produziert;
• jede installation swap ist eine single store-Größe IntPtr, die garantiert atomar sind für alle jeweiligen Plattform Bitanzahl;
• schließlich, und technisch absolut entscheidend, um die perfekte formale Korrektheit, arbeiten Produkte der "Verlierer" werden zurückgefordert, die von GC und somit kein Leck. In diese Art von Rennen, Verlierer sind alle Rennfahrer mit Ausnahme der letzten - finisher (da alle anderen Bemühungen bekommen munter und kurzerhand überschrieben mit identischem Ergebnis).

Obwohl ich glaube, dass diese Punkte zu kombinieren, um vollständig schützen Sie den code unter jeden möglichen Umstand, wenn Sie immer noch misstrauisch oder vorsichtig von den insgesamt zu dem Ergebnis, können Sie immer fügen Sie eine zusätzliche Schicht von bulletproofing:

var tmp = (Func<Ectx, Sctx>)dm.CreateDelegate(typeof(Func<Ectx, Sctx>));
Thread.MemoryBarrier();
__get = tmp;
return tmp(arg);

Es ist nur ein paraniod-version. Wie bei den früheren condensed one-liner, die .NET-Speicher-Modell garantiert, dass es genau einen store--und keine holt--Ort des '__get'. (Der vollständige erweiterte Beispiel ganz oben hat einen extra Arbeitsspeicher Holen, aber klingen immer noch durch den zweiten Punkt) Wie ich bereits erwähnte, keine dieser nötig sein sollte, für die Richtigkeit, aber es könnte in der Theorie, geben einen kleinen performance-bonus: durch abschließend endet das Rennen früher, die aggressive Spülen könnte, in einem extrem seltenen Fall verhindern, dass eine spätere Anrufer, auf eine dirty cache line von unnötig (aber wieder harmlos) racing.

Doppel-thunking

Anrufe in den letzten hyper-schnell-Methode sind noch thunked durch die statische Erweiterung Methoden wie oben gezeigt.
Denn wir müssen auch irgendwie darstellen entry point(s), die tatsächlich vorhanden sind zur compile-Zeit compiler binden vor und übertragen von Metadaten. Die Doppel-thunk ist ein kleiner Preis zu zahlen, für die überwältigende Bequemlichkeit stark typisierte Metadaten und intellisense in der IDE code angepasst, die können eigentlich nicht gelöst werden, erst zur Laufzeit. Doch es läuft mindestens so schnell wie eine statisch kompilierte code Weg schneller, dass dabei eine Reihe von Reflexion bei jedem Anruf, damit wir das beste aus beiden Welten!