Warum SynchronizationContext funktioniert nicht richtig?

Habe ich folgenden code:

[TestMethod]
public void StartWorkInFirstThread()
{
    if (SynchronizationContext.Current == null)
        SynchronizationContext.SetSynchronizationContext(
            new SynchronizationContext());

    var syncContext = SynchronizationContext.Current;

    Console.WriteLine("Start work in the first thread ({0})", 
        Thread.CurrentThread.ManagedThreadId);

    var action = ((Action) DoSomethingInSecondThread);
    action.BeginInvoke(CallbackInSecondThread, syncContext);

    //Continue its own work
}

private static void DoSomethingInSecondThread()
{
    Console.WriteLine("Do something in the second thread ({0})", 
        Thread.CurrentThread.ManagedThreadId);   
}

private void CallbackInSecondThread(IAsyncResult ar)
{
    Console.WriteLine("Callback in the second thread ({0})", 
        Thread.CurrentThread.ManagedThreadId);
    var syncContext = (SynchronizationContext) ar.AsyncState;
    syncContext.Post(CallbackInFirstThread, null);
}

private void CallbackInFirstThread(object obj)
{
    Console.WriteLine("Callback in the first thread ({0})",
        Thread.CurrentThread.ManagedThreadId);
}

Erwarte ich Letzte Methode, die ausgeführt werden, im ersten thread, d.h. der erste thread, in dem Synchronisierungskontext entnommen ist, denn ich nenne Post() Methode in diesen Kontext. I. e. so etwas wie dieses:

Start work in the first thread (28)
Do something in the second thread (17)
Callback in the second thread (17)
Callback in the first thread (28)

Ist es nicht der Sinn des SynchronizationContext? Aber eigentlich habe ich folgende Ausgabe:

Start work in the first thread (28)
Do something in the second thread (17)
Callback in the second thread (17)
Callback in the first thread (7)

Was ist das problem? Macht das etwas schief gehen mit SynchronizationContext-oder habe ich etwas Missverständnis?

Update: ich nenne diese Methode als unit-test mit Resharper test-runner.

Sie haben nicht uns gezeigt, wie diese aufgerufen werden, oder was mit der Synchronisation Kontext (z.B. einer WinForms-Ereignis-Schleife). Bitte aktualisieren Sie Ihre Frage mit einem kurzen, aber vollständigen Beispiel.
Dies ist unit-test (MS-Test-Framework), ich benutze Resharper unit-test-runner.

InformationsquelleAutor Alex Kofman | 2010-10-08

8

Sehen http://www.codeproject.com/KB/threads/SynchronizationContext.aspx

Es ist die Antwort, die Sie brauchen. Sie überschreiben muss SynchronizationContext machen es richtig, den Umgang mit Ihren-Operationen.

Lesen ab:

Beachten Sie, dass DoWork ausgeführt
thread 11 ist der gleiche thread wie Run1.
Nicht viel von einem SynchronizationContext
in den Haupt-thread. Warum? Was
auf geht? Na ja... Das ist das Teil
wenn Sie erkennen, dass nichts ist für
frei im Leben. Threads können nicht nur
zwischen Kontexten Umschalten, zwischen, Sie
muss eine Infrastruktur aufgebaut-in
in Ihnen, um so zu tun. Die Benutzeroberfläche
thread, zum Beispiel, verwendet eine Nachricht
Pumpe, und in seinen
SynchronizationContext es nutzt
das Nachrichtensystem synchronisieren in der UI
thread.
- Senden Sie einfach ruft die Delegierten auf der aufrufende thread (keine thread-Wechsel jeglicher Art), und die Post tut das gleiche, aber verwendet einfach den ThreadPool, um es in einer async-Mode. Meiner Meinung nach, diese Klasse sollte Abstrakt sein. Die Standard-Implementierung dieser Klasse ist verwirrend und nutzlos.
- Absolut einverstanden.
- Wenn SynchronizationContext war Abstrakt, was würden Sie erstellen, zuweisen SynchronizationContext.Current im unit-tests? Es ist besser als nichts.
- es könnte ein NoSynchronizationContext Klasse für, die.
InformationsquelleAutor Alex Yakunin
5

Default-Implementierung von SynchronizationContext nur ausführt, übergeben Delegierten in die aufrufende thread (in dem thread, ruft die Sende - /Post-Methode nicht der thread, fängt Kontext). Wenn Sie einige bestimmte Verhaltensweisen, wie die thread-Affinität für einige Operationen, die Sie durchführen sollten, diese manuell. BCL enthält einige out-of-box-Implementierungen für die Vereinfachung der Benutzeroberfläche Interoperabilität, wie WindowsFormsSynchronizationContext oder DispatcherSynchronizationContext.
- So brauche ich "nur ausführen, übergeben Delegierten in die aufrufende thread"
- Aber Es funktioniert nicht, Er führt es in einem anderen thread.
- Send ruft den Delegaten auf den aufrufenden thread, Post Warteschlangen an den thread-pool.
InformationsquelleAutor desco

Ihre Erwartung ist falsch, denn es gibt keinen Allgemeinen Weg zu "injizieren" ein Abgeordneter in einem Laufenden thread. Ihre "ersten thread" gestartet wurde in der test-runner, die ausgeführt wird, einen oder mehrere tests, und werden dann aufhören - es gibt keine Möglichkeit, Sie zu unterbrechen und sagen, es zu führen CallbackInFirstThread. Die SynchronizationContext Klasse läuft Post-ed-Delegierten in der thread-pool, denn das ist die einzige Möglichkeit, die es hat.

Abgeleiteten Klassen wie WindowsFormsSynchronizationContext nutzen die message-loop in WinForms-Anwendungen zu übergeben, die Post-ed-Delegat der UI-thread, aber es gibt keine Entsprechung in einem test-runner.

Wenn Sie prüfen wollen, welche SynchronizationContext den code, den Sie testen wollen ist verwenden, können erstellen Sie Ihre eigene abgeleitete Klasse, setzt ein flag das können Sie in Ihrem test. Hier ist ein Beispiel:

public class TestSynchronizationContext : SynchronizationContext
{
    [ThreadStatic]
    private static object _CurrentPostToken;
    ///<summary>
    ///Gets the context's token, if the current thread is executing a delegate that
    ///was posted to this context; otherwise, null.
    ///</summary>
    public static object CurrentPostToken
    {
        get
        {
            return _CurrentPostToken;
        }
    }

    public object Token { get; private set; }

    ///<summary>
    ///Gets a WaitHandle that is set after the context executes a posted delegate.
    ///</summary>
    public AutoResetEvent PostHandle { get; private set; }

    public TestSynchronizationContext(object token)
    {
        Token = token;
        PostHandle = new AutoResetEvent(false);
    }

    public override void Post(SendOrPostCallback d, object state)
    {
        try
        {
            _CurrentPostToken = Token;
            //Execute the callback on this thread, so that we can reset the context
            //when it's finished.
            d(state);
        }
        finally
        {
            _CurrentPostToken = null;
        }

        //The test method will wait on this handle so that it doesn't exit before
        //the synchronization context is called.
        PostHandle.Set();
    }
}

In StartWorkInFirstThread, den Kontext zu einer Instanz von TestSynchronizationContext:

SynchronizationContext.SetSynchronizationContext(
        new TestSynchronizationContext(new object()));

Nach Aufruf BeginInvoke, müssen Sie warten, bis die Post geschehen, bevor Sie beenden den test, so rufen Sie:

((TestSynchronizationContext)SynchronizationContext.Current).PostHandle.WaitOne(1000);

In CallbackInFirstThread können Sie überprüfen, welche Rahmen verwendet wird, mit etwas wie:

Assert.IsNotNull(TestSynchronizationContext.CurrentPostToken);

Der Punkt ist, dass es keine einfache Möglichkeit, um tatsächlich post zurück zu dem ersten thread, aber Sie können überprüfen, dass die richtigen Kontext verwendet wird, so dass, wenn Ihr code ausgeführt wird, in einer realen Anwendung wird der callback ausgeführt werden, in dem UI-thread.

InformationsquelleAutor Rory MacLeod

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.