Stimmt das war ungenau. Diese Strukturen sind nötig für asynchrone und gepufferte IO Operationen. Das trifft auf das Filesystem API zu, auch auf zb. COM oder USB API und eben auf Sockets. Neben einem Event kann in dieser Datenstruktur noch wesentlich mehr beeinflusst werden. Sockets, COM, USB und oft auch File Operationen die per Events asynrchon signalisiert werden machen meistens nur mit dieser Overlapping Struktur einen Sinn. Das Overlapping hat sich deshalb bei mir so eingeprägt weil es mit Überlappung (zeitlichen Überschneidungen) zu tuen hat, also asynchron ist.

Es geht aber noch weiter !

und ergänzend kommt nun das Threadhandling als Verbesserung hinzu.

Denn stell dir vor das alles machst du in einem Thread. Der Thread wartet nun nicht mehr auf das synchrone Abarbeiten der IO Operation sondern legt sich mit WaitForSingle/MultipleObjects selber schlafen. Er verbraucht so keine Rechenzeit und wird nun statt ständig zu warten bzw. zu pollen direkt vom OS per Event signalisiert das was fertig ist. Und ganz wichtig ! Statt sequientiell nacheinander mehrere solcher IO Operation nacheinander zu erledigen (mit unbekannter Wartezeit) startet er einfach mehrere solcher asynchronen Vorgänge und wartet dann einfach per WaitForMultipleObjects() auf das Eintreffen eines Signales einer dieser IO Operationen. Je nach Dauer dieser Operationen wird er mit der ersten fertigen Operation anfangen. Gerade bei Sockets mit ihren unvorhersagbarem Timing also ideal.

Events, Overlapping, IO Operationen, Semaphore und sogar der Messagequeue machen dann mit Hilfe der Threads so richtig Sinn.

Gruß Hagen