Event - Latenz

[TomyN]

Hallo,

Ich bin gerade über eine Sache gestolpert, die ich nicht so ganz nachvollziehen kann:
- Ich habe einen Thread mit Priorität tpNormal. Da ist ein waitForSingleObject(Event, ... ) drin.
- In meiner Anwendung setzte ich den Event ('Stinknormaler' Autoreste Event (aus der windows unit und nicht aus den syncObjs)
- Es dauert bis zu 20ms, bis der 'Event' ankommt, d.h. das waitFor 'durchschaltet'
- Der Thread braucht ca. 1 ms für einen Durchlauf
- Die Events kommen etwas im 10ms Raster, d.h. ab un zu wird ein Event 'verschlafen', was alles durcheinander bring :-(

Ist das normal, übersehe ich was oder gibt es eine schnellere Möglichkeit der 'Threadalarmierung' ?

Freue mich über jede Idee

Tomy

[shebang]

Schau dir mal timeBeginPeriod an, die standardmäßige Zeitgeberauflösung unter Windows beträgt 15,625 ms.

[TomyN]

Interessanter Gedanke, aber die Timerauflösung steht schon auf 1ms ....

[himitsu]

* Windows ist kein RealTime-System
* du redest hier von 2 Threads, aber es gibt hunderte tausende Threads, welche sich eine homöopathische Dosis an CPU-Kernen teilen, wo jeder Thread "standardmäßig" ein paar Millisekunden abeitet und dann Pause macht

Es liegt in der Sache der Natur, dass der andere Thread somit ein bisschen braucht, bis er reagieren kann.

Zitat:

Der Thread braucht ca. 1 ms für einen Durchlauf

Wozu dann ein Thread?

[Phoenix]

Zitat:

Zitat von himitsu (Beitrag 1535908)

wo jeder Thread "standardmäßig" ein paar Millisekunden abeitet und dann Pause macht

So eine Zeitscheibe (nennt sich Quantum) liegt bei einem Desktop-Windows (nicht Windows Server) wohl irgendwo zwischen 20 und 60ms. Dann kommen erstmal viele viele andere Threads von anderen Prozessen dran bevor wieder ein eigener Thread auf der SPU landet.

Bei einer Server-SKU soll so ein Quantum wohl relativ konstant bei 120ms liegen. Unixe/Linuxe schedulen wohl auch um die 100ms.
Das ganze sind ungefähre Angaben. Der Quellcode des Windows-Schedulers liegt nicht offen und Microsoft schweigt sich zu den exakten Zeiten aus.

Zitat:

Zitat von himitsu (Beitrag 1535908)

Zitat:

Der Thread braucht ca. 1 ms für einen Durchlauf

Wozu dann ein Thread?

Genau. Warum dann ein Thread?
Wenn alle 10ms ein Event rein kommt, und das 1ms braucht zum abarbeiten, dann hat man 9ms nix zu tun. Die kann man natürlich mit Kommunikation zwischen den Threads füllen, effizient ist das aber nicht :)

[himitsu]

Und dann kommt es auch drauf an, ob der andere Thread zufällig grade aktiv ist, bzw. kurz danach wird, oder ob er grade aktiv war und nun 'ne Weile weg ist.

Sleep und WaitFor sind aber nett und geben sofort die Ausführung an Windows zurück ... verbrauchen also nicht den komplett ihnen zustehende Slott, wodurch die anderen Threads somit schneller wieder dran kommen.
Da die meisten Threads meistens schlafen, muß somit kein Thread wirklich sehr lange warten, bis er wieder dran ist.

Soll ein Thread eine gewisse "schnelle" Aufgabe in einem Slott durchführen, dann könnte man kurz vorher ein Sleep(0) einfügen und danach arbeitet der Code von beginn des neuen Slotts, aber garantiert ist es "normal" dennoch nicht, dass es wirklich durcharbeitet, außer man fummelt noch bissl an der Priorität ud Co. rum, aber auch da ist nichts garantiert.

z.B. könnte man alle anderen Threads/Prozesse auf die anderen Kerne beschränken und den einen Thread alleinig an einen bestimmteh Kern binden ... grundsärzlich würde er dann durchlaufen (aber durch Treiber, Interrupts usw. könnte er dennoch unterbrochen werden).
Außerdem hat es die CPU/Windows nicht gern, wenn EIN Core brennt (durchackert), drum schubst z.B. Windows 11 vor allem die arbeitenden Threads alle 30 Sekunden zwischen den Cores hin und her, um die Wärmebelastung zu verteilen.

[TomyN]

Über windows und realtime kann man geteilter Meinung sein, was natürlich an der Definition von realtime hängt. So zeigt zum Beispiel SAC was unter windows möglich ist.
Warum ein Thread, ganz einfach, weil das SDK folgendes sagt:

Zitat:

directProcess suggests to the host whether it should immediately start processing
(directProcess == ASIOTrue), or whether its process should be deferred
because the call comes from a very low level (for instance, a high level
priority interrupt), and direct processing would cause timing instabilities for
the rest of the system. If in doubt, directProcess should be set to ASIOFalse.

Ich lese das so, dass ich informiert werde, dass Daten da sind und ich sie abholen soll. Alledings eben nicht in dieser (Interrupt?) Routine. Da dachte ich an Thread und Event. Gibt es andere Ideen (APC spukt mir durch den Kopf, aber da hab ich keine Ahnung davon) oder so wüste Gedanken wie ein Timer mit Routine o.ä.

[himitsu]

Zitat:

Der Thread braucht ca. 1 ms für einen Durchlauf

Wenn das so schnell geht, warum dann überhaupt mit Threads, Asychron oder sonstwas anfangen?