TPL Dataflow, was ist der funktionale Unterschied zwischen Post() und SendAsync()?

Question

Ich bin verwirrt über den Unterschied zwischen dem Senden von Elementen über Post() oder SendAsync(). Mein Verständnis ist, dass in allen Fällen, sobald ein Element den Eingabepuffer eines Datenblocks erreicht hat, die Kontrolle an den aufrufenden Kontext zurückgegeben wird, richtig? Warum sollte ich dann SendAsync brauchen? Wenn meine Annahme falsch ist, frage ich mich im Gegensatz, warum jemand jemals Post() verwenden würde, wenn die ganze Idee der Verwendung von Datenblöcken darin besteht, eine gleichzeitige und asynchrone Umgebung einzurichten.

Ich verstehe natürlich den Unterschied technisch darin, dass Post() einen bool zurückgibt, während SendAsync eine erwartete Aufgabe von bool zurückgibt. Aber welche Auswirkungen hat das? Wann würde die Rückgabe eines Bool (was ich verstehe, ist eine Bestätigung, ob der Gegenstand in die Warteschlange des Datenblocks gestellt wurde oder nicht) jemals verzögert werden? Ich verstehe die allgemeine Idee des Async/erwarten Parallelitätsframework, aber hier macht es nicht viel Sinn, denn anders als ein Bool wird das Ergebnis dessen, was mit dem übergebenen Element gemacht wird, nie an den Aufrufer zurückgegeben, sondern stattdessen in einem "out-queue" und entweder an verknüpfte Datenblöcke weitergeleitet oder verworfen.

Und gibt es irgendwelche Leistungsunterschiede zwischen den beiden Methoden beim Senden von Artikeln?

Answer 1

Um den Unterschied zu sehen, brauchen Sie eine Situation, in der Blöcke ihre Nachrichten verschieben. In diesem Fall gibt Post sofort false zurück, während SendAsync eine Task zurückgibt, die abgeschlossen wird, wenn der Block entscheidet, was mit der Nachricht zu tun ist. Die Task wird ein true Ergebnis haben, wenn die Nachricht akzeptiert wird, und ein false Ergebnis wenn nicht.

Ein Beispiel für eine aufschiebende Situation ist eine nicht gierige Verbindung.Ein einfacheres Beispiel ist, wenn Sie BoundedCapacity gesetzt:

[TestMethod] 
public void Post_WhenNotFull_ReturnsTrue() 
{ 
    var block = new BufferBlock<int>(new DataflowBlockOptions {BoundedCapacity = 1}); 

    var result = block.Post(13); 

    Assert.IsTrue(result); 
} 

[TestMethod] 
public void Post_WhenFull_ReturnsFalse() 
{ 
    var block = new BufferBlock<int>(new DataflowBlockOptions { BoundedCapacity = 1 }); 
    block.Post(13); 

    var result = block.Post(13); 

    Assert.IsFalse(result); 
} 

[TestMethod] 
public void SendAsync_WhenNotFull_ReturnsCompleteTask() 
{ 
    // This is an implementation detail; technically, SendAsync could return a task that would complete "quickly" instead of already being completed. 
    var block = new BufferBlock<int>(new DataflowBlockOptions { BoundedCapacity = 1 }); 

    var result = block.SendAsync(13); 

    Assert.IsTrue(result.IsCompleted); 
} 

[TestMethod] 
public void SendAsync_WhenFull_ReturnsIncompleteTask() 
{ 
    var block = new BufferBlock<int>(new DataflowBlockOptions { BoundedCapacity = 1 }); 
    block.Post(13); 

    var result = block.SendAsync(13); 

    Assert.IsFalse(result.IsCompleted); 
} 

[TestMethod] 
public async Task SendAsync_BecomesNotFull_CompletesTaskWithTrueResult() 
{ 
    var block = new BufferBlock<int>(new DataflowBlockOptions { BoundedCapacity = 1 }); 
    block.Post(13); 
    var task = block.SendAsync(13); 

    block.Receive(); 

    var result = await task; 
    Assert.IsTrue(result); 
} 

[TestMethod] 
public async Task SendAsync_BecomesDecliningPermanently_CompletesTaskWithFalseResult() 
{ 
    var block = new BufferBlock<int>(new DataflowBlockOptions { BoundedCapacity = 1 }); 
    block.Post(13); 
    var task = block.SendAsync(13); 

    block.Complete(); 

    var result = await task; 
    Assert.IsFalse(result); 
} 

Answer 2

Die Dokumentation macht dies einigermaßen klar, IMO. Insbesondere für Post:

Diese Methode wird zurückkehren, sobald der Zielblock den Punkt zu akzeptieren oder abzulehnen, aber wenn nicht anders diktiert durch spezielle Semantik des Zielblockes, es wartet nicht, bis das Produkt tatsächlich entschieden hat, wird verarbeitet.

Und:

Für Zielblocks, die dargebotener Nachrichten unterstützen zu verschieben, oder für Blöcke, die in ihrer Post Umsetzung mehr Verarbeitungs tun können, sollten SendAsync verwenden, die sofort zurück und wird das Ziel ermöglichen verschieben Sie die gepostete Nachricht und später konsumieren sie nach SendAsync zurück.

Mit anderen Worten, während beide die Nachricht in Bezug auf Verarbeitung asynchron sind, erlaubt SendAsync den Zielblock, ob oder nicht zu entscheiden die Nachricht asynchron akzeptieren.

Es klingt wie SendAsync ist eine allgemein "mehr asynchrone" Ansatz, und eine, die wahrscheinlich im Allgemeinen gefördert wird. Was ist nicht klar für mich ist, warum beide erforderlich sind, wie es sicherlich klingt wie Post ist weitgehend gleichwertig mit SendAsync und dann nur auf das Ergebnis warten.