TThread mit Queue und Events

[Rollo62]

Zitat:

Zitat von jaenicke (Beitrag 1549027)

... sehe ich auch keinen Grund, das mit Events oder ähnlichem umzusetzen. Das Ergebnis ist das gleiche, ...

Vielleicht wird darauf abgezielt, dass Windows Sleep nicht unterbrechbar ist und generell die Events schon?
Deshalb könnte es mit Events insgesamt reaktiver werden und auch sicherer gegen Deadlocks, weil Events sich von aussen killen lassen.

Die Timer-Präzision sollte nicht den Unterschied machen, das ist meiner Meinung nach gleich.
Nur bei Cross-Plattform gibt es da generell Vorteile, aber dann auch bei Sleep und WaitFor gleichermaßen.

[Mavarik]

Zitat:

Zitat von Rollo62 (Beitrag 1549016)

Hmmm, meinst Du damit, er SOLLTE besser kein Sleep einsetzen? .... oder er kann gar kein Sleep ausführen? :gruebel:

Natürlich geht ein Sleep, aber ich nutze doch einen Thread um etwas parallel oder schneller zu machen.
Daher macht für mich ein Sleep in einem Thread nie einen Sinn.

Zitat:

Zitat von jaenicke (Beitrag 1549027)

Wenn es rein um eine Verzögerung geht, sehe ich auch keinen Grund, das mit Events oder ähnlichem umzusetzen. Das Ergebnis ist das gleiche, ob ich auf ein Event eine bestimmte Zeit bis zum Timeout warte oder dies mit Sleep direkt mache.

Ob das das gleiche ist möchte ich (ungetestet) bezweifeln. Aber in diesem Beispiel nutzt man ja einen TEvent um keinerlei CPU Zyklen zu verschwenden. Immer warten und pollen macht halt überhaupt keinen Sinn, wenn ich auch auf einen Event in Best Case: ~1–10 µs (Mikrosekunden) reagieren kann.

Zitat:

Zitat von jaenicke (Beitrag 1549027)

Ich persönlich finde den zusätzlichen Code für z.B. ein Event nicht gerade gut für die Lesbarkeit, denn das Event hat ja selbst dann gar keine Funktion.

Doch genau das was er soll... Warten bis etwas neues in der Queue ist. (Oder Terminate)

Mavarik :coder:

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1549058)

Doch genau das was er soll... Warten bis etwas neues in der Queue ist. (Oder Terminate)

Ich habe ja geschrieben, dass das für den Fall passt.

Aber wer soll das Event auslösen, wenn ich z.B. einen Server pollen möchte, ob er neue Daten hat? Aber eben mit etwas Wartezeit dazwischen.

Es gibt auch andere Konstellationen als dass ein Thread zur Beschleunigung durch Parallelisierung dienen soll oder auf konkret abfragbare Events wartet.

[Kas Ob.]

Zitat:

Zitat von jaenicke (Beitrag 1549059)

Zitat:

Zitat von Mavarik (Beitrag 1549058)

Doch genau das was er soll... Warten bis etwas neues in der Queue ist. (Oder Terminate)

Aber wer soll das Event auslösen, wenn ich z.B. einen Server pollen möchte, ob er neue Daten hat? Aber eben mit etwas Wartezeit dazwischen.

I don't recall a single Windows IO operation that doesn't support both blocking and non-blocking, synchronous or asynchronous, they all fall in one way or other under overlapped, and they all have the possibility to attach an event to automatically triggered, as for the same example like a server then either
1) block on "recv" and skip the event altogether or
2) block on "select" to get the state of the socket and have the exact moment of/for receiving data, or
3) use WSAEventSelect and WSAAsyncSelect , these are powerful to combine with other complex or non-complex operation, events here become central notification for one or more threads.
4) IOCP and don't even wait manually, get the operation and process the data in place within the thread knowing there is other threads allowed to process other client...
5) ..
6) ..
there is many approaches and that only for handling sockets on server or client side, same goes for files ReadFile and ReadFileEx, they have differences and can combined in many different ways, if you prefer events then overlapped with supplied event is the way to go, work like charm with com and legacy communication ports, allowing you to utilize the maximum throughput being writing files to disk or sending data to hardware wire or a driver ...

The overlapped design and operation are powerful and efficient, the core of overlapped mechanism is low level kernel triggered events.

Zitat:

Zitat von jaenicke (Beitrag 1549059)

Es gibt auch andere Konstellationen als dass ein Thread zur Beschleunigung durch Parallelisierung dienen soll oder auf konkret abfragbare Events wartet.

Of course there is, there is always such needed design where time interval is needed at the exact point, in other words, time is essential for non performed operation or non triggered event, may be a timer, may be we want to control the time out for a socket, short one and dont want to depend on socket provider timeout..etc ,
other than that i see polling as waste of time and CPU cycle as as Mavarik, for fast and lazy or limited usage then yes, poll then execute then sleep for short time, but with servers with many clients and many threads, this is a waste.