Warum ist asynchrone IO bevorzugt

Also habe ich einige WIN32-Socket-Programmierung gemacht und ich versuche zu verstehen, warum Overlapped IO bevorzugt wird. Insbesondere frage ich mich, warum so etwas wie diesesWarum ist asynchrone IO bevorzugt

if (WSARecv(
      socket, 
      dataBuf, 
      1, 
      NULL, 
      &flags, 
      &ov, 
      NULL) 
      == SOCKET_ERROR) { 
    if (WSAGetLastError() == WSA_IO_PENDING) 
    { 
     if (WSAWaitForMultipleEvents(1, &ov.hEvent, FALSE, INFINITE, FALSE) == WAIT_TIMEOUT) 
     { 
      return FALSE; 
     } 
    } else { 
     return FALSE; 
    } 
} 
// ... more code here 
return TRUE;

über einen normalen IO Anruf bevorzugt ist wie dieser

recv(socket, dataBuf, bufLen), 0);

Von meinem Verständnis wird der erste Anruf sperren, wenn das IO-Ereignis nicht tat Bei WSAWaitForMultipleEvents wird der Aufruf beendet, während der zweite Aufruf direkt bei recv blockiert wird, bis Daten eingetroffen sind. Was ist also der eigentliche Vorteil, wenn der IO Call etwas später blockiert wird? Ist es das IF Sie hatten etwas, was Sie tun konnten, bevor Sie darauf warten, dass Sie das tun würden?

Wenn das der Fall ist Overlapped IO lohnt es/benötigt in Anwendungen, in denen Sie nichts tun können, bis Daten angekommen sind?

Quelle

2016-08-22 FrozenHawk

Der Fall, den Sie zeigen, ist nicht der typische Grund, irgendwelche asynchronen I/O zu verwenden, ganz im Gegenteil würde ich sagen (da es, wie Sie bemerkt haben, nicht wirklich asynchron ist).

Der typische Grund für asynchrone E/A ist nur, weil es asynchron ist, Ihr Programm kann mit etwas anderem weitermachen, anstatt auf den Abschluss der E/A-Operation zu warten.

Quelle

2016-08-22 02:23:41

Können Sie ein Beispiel für etwas geben, das während des Wartens auf Daten ausgeführt werden kann? – FrozenHawk

Das kanonische Beispiel ist eine Anwendung, die mehr als einen aktiven Socket aufweist, z. B. einen Server. Sie können entweder einen Thread für jeden Client verwenden, der einfach ist, aber schlecht skaliert, oder Sie können asynchrone E/A verwenden. –

Ich hätte gedacht, dass die kanonische Anwendung überhaupt eine GUI-Anwendung ist, die auf Benutzereingaben und Neuaufruftelefonate reagieren muss, damit sie nicht mehr reagiert. –

Asynchroner E/A-Speicher Thread-Ressourcen.

Insbesondere wenn Sie einige Clientanforderungen über synchrone E/A verarbeiten, weisen Sie 1 Thread für es zu. Was funktioniert, wenn Sie 1 Client haben. Oder 10 Kunden.

Wenn Sie 10000 Clients haben, müssten Sie 10K-Threads für sie erstellen, um sie zu bedienen. Was ist möglich, aber in vielen Fällen ineffizient.

Die Verwendung asynchroner E/A ermöglicht die Verarbeitung einer sehr großen Anzahl von Clients in einem Thread (eine bestimmte Anzahl hängt von der OS/Architektur ab). Normalerweise kann ein solcher Ansatz nur ein wenig langsamer sein als der dedizierte Thread für eine kleine Anzahl von Clients (als Request-Behandlung wird serialisiert), aber in anderen Fällen viel besser.

Quelle

2016-08-22 08:05:44

Sie sprechen hier wirklich von [E/A Completion Ports] (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365198.aspx). Die ausschließliche Verwendung asynchroner E/A verwendet Systemressourcen nicht effizient. – IInspectable

Warum ist asynchrone IO bevorzugt

Antwort

Verwandte Themen