Unterschiede zwischen C# async und Java ExecutorService

Question

C# haben eine coole neue Funktion

public Task<string> async f() 
{ 
    string r = LongCompute(); 
    return r; 
} 

aber ist das nicht gleichbedeutend mit

public Future<String> f() { 
    return Globals.executorService.submit(new Callable<String>() { 
     public String call() throws Exception { 
      String r = longCompute(); 
      return r; 
     } 
    }); 
} 

wo in Java Sie mehr Flexibilität haben den Threadpool zu wählen, in dem Die Aufgabe würde ausgeführt werden.

Was erwarten über? Es ist gleichbedeutend mit nur erhalten Aufruf

string s = await f(); 

ist wie

String s = f().get(); 

Gibt es etwas zu C#, oder ist es in der Tat nur ein syntaktischer Zucker in der Java-Version? (Ich bin kein C# Guru, also könnte ich etwas verpassen).

Answer 1

Nein, await ist nicht wie nur get() anrufen. Es gibt wesentlich mehr dazu.

Wenn Sie einen Ausdruck await in C# verwenden, erstellt der Compiler effektiv eine Fortsetzung, so dass die Methode sofort zurückkehren und die Verarbeitung nur fortsetzen kann, wenn das Erwartete noch nicht abgeschlossen ist. Die Fortsetzung wird in einem entsprechenden Kontext ausgeführt - also, wenn Sie auf einem UI-Thread vor dem await Ausdruck sind, werden Sie danach auf dem UI-Thread fortsetzen werden, ohne jedoch den UI-Thread blockiert, während Sie für das Ergebnis auf jemand warten. Zum Beispiel:

public async void HandleButtonClick(object sender, EventArgs e) 
{ 
    // All of this method will run in the UI thread, which it needs 
    // to as it touches the UI... however, it won't block when it does 
    // the web operation. 

    string url = urlTextBox.Text; 
    WebClient client = new WebClient(); 
    string webText = await client.DownloadStringTaskAsync(url); 

    // Continuation... automatically called in the UI thread, with appropriate 
    // context (local variables etc) which we used earlier. 
    sizeTextBox.Text = string.Format("{0}: {1}", url, webText.Length); 
} 

Letztlich ist es alles syntaktischen Zucker, aber viel kompliziertere Zucker als das, was Sie gezeigt haben.

Es gibt eine Menge von Informationen im Internet verfügbar bereits. Zum Beispiel:

• Eric Lippert's blog
• Die Visual Studio async home page
• My own blog posts about async

Answer 2

Genau richtig Jon Skeet Antwort zu verlängern.

Die kein Java-Analogon von C# ist Ausdrücke erwarten. Hoverer haben einige Java-Frameworks gleiche Funktionalität:

• Kilim: https://github.com/kilim/kilim
• Apache JavaFlow: http://commons.apache.org/sandbox/commons-javaflow/

In der Tat, sie erzeugen State-Maschinencode on-fly.

Answer 3

Jon nicht erklären, den eigentlichen Punkt.

Java ExecutorService basiert auf Fäden, während C# 's await kann gesagt werden, werden basierend auf Fasern.

Beide ermöglichen Multitasking, bei dem Rechenressourcen zwischen gleichzeitigen Funktionen aufgeteilt werden (dh Funktionen, die "gleichzeitig" ausgeführt werden). Die erste Art von Multitasking heißt Präventiv, während die zweite kooperative. In der Vergangenheit wurde präemptives Multitasking als fortschrittlicher und kooperativer angesehen. In der Tat, bevor präemptives Multitasking von den Betriebssystemen der Verbraucher unterstützt wurde, haben Computer wirklich gesaugt. Preemptives Multitasking hat jedoch seine Nachteile. Es kann schwer zu programmieren sein und es benötigt mehr Speicher. Der Hauptunterschied zwischen den beiden ist, dass präemptives Multitasking es der Laufzeit (normalerweise dem Betriebssystem selbst) ermöglicht, jede Funktion zu jeder Zeit zu stoppen und eine andere Funktion zu starten (und sie gleichzeitig auf verschiedenen CPUs auszuführen). In der Zwischenzeit erfordert kooperatives Multitasking, dass die Running-Funktion beendet oder freiwillig angehalten wird. Die meisten von uns kennen präemptives Multitasking in Form von Multithreading sowie die damit verbundene sorgfältige Programmierung. Weniger bekannt ist das kooperative Multitasking, das heutzutage oft als Fasern oder Koroutinen bezeichnet wird (in diesem Fall ist es im Benutzerland innerhalb der Threads eines präventiven Betriebssystems implementiert).

Auf jeden Fall ist der Punkt, dass ExecutorService und await nicht direkt vergleichbar ist, und await ist nicht im allgemeinen überlegen echten Multithreading (außer, dass es schön syntaktischen Zucker kennzeichnet). C# 's Grund für die Einbeziehung await (und basierend auf kooperativen Multitasking) ist, dass die wichtigsten GUI-Toolkits auf der Plattform nicht für Multithreading ausgelegt sind und das Refactoring zur Unterstützung der Parallelität eine Menge Arbeit kosten würde. Kooperatives Multitasking funktioniert gut für die Benutzeroberfläche, da die meisten Ereignisbehandlungsroutinen kurz sind und seriell ausgeführt werden können. await erweitert das Konzept der Ereignisschleife, indem lange Event-Handler sich selbst pausieren lassen und fortsetzen, nachdem die Rendering-Funktion eine Chance zum Ausführen hat. All dies geschieht in einem einzigen Thread auf einem einzelnen CPU-Kern.

Wo beide finden gemeinsame Grund ist, dass sie beide Formen von Multitasking sind, und Future.get und await Task sind beide Formen der Synchronisation.

Wie erwartet, ist C# nicht ohne gute Unterstützung für Threads und Thread-Pools. Ebenso enthält Java Fasern/Co-Routinen/Async in vielen Bibliotheken, wie Servlet 3.0 und javafx.concurrent.Task.

Als Reaktion auf Jon Skeet: Fortsetzung (wie der Benutzerland-Implementierungsmechanismus von Fasern genannt wird) ist nicht trivial, aber Threads sind nicht weniger anspruchsvoll in ihrer Implementierung. Jon wurde vielleicht abgeworfen, weil die Algorithmen hinter Threads im Betriebssystem und nicht im Compiler oder in der .NET-Laufzeitumgebung liegen.