Dazu ist ein klein wenig wichtig zu wissen, wie sich Windows verhält wenn man Threads startet.
Ein Thread der erzeugt wird wird, wenn man ihn Starten möchte, nicht sofort gestartet. Die Windows-
API sagt dem Thread lediglich, dass er jetzt loslaufen kann, und der Windows-Scheduler kann ihn dann (muss ihn aber nicht sofort) beim nächsten mal wenn er arbeitet berücksichtigen und auf die CPU legen.
Das passiert frühestens(!) wenn der Haupt-Thread Deiner Anwendung yielded (das bedeutet: Rechenzeit abgibt). Warum das passiert (seine Zeitscheibe / Quantum ist abgelaufen, er blockiert wegen I/O, er gibt mit Sleep freiwillig Rechenzeit ab) ist dabei egal, aber der zweite Thread kommt eben frühestens das erste mal auf die CPU wenn der Hauptthread frei macht.
Auch danach kannst Du bei mehreren Threads nicht sicher sein, dass die wirklich Zeitgleich laufen. Es kann passieren, dass der Windows-Scheduler die Threads alle schön nacheinander ausführt.
Auch wichtig: Nur der UI-Thread kann das UI aktualisieren. Wenn der gerade nicht läuft wenn die anderen beiden Threads werkeln, bekommt das UI das nicht mit. Und da Du den im Prinzip mehr schlafen legst als das er Rechnet (Sleep-Aufrufe) kann der nicht viel machen.
Noch ein Wort zu den Quantums: Eine Zeitscheibe auf der CPU sind bei Windows aktuell vermutlich irgendwas zwischen 20 und 60 Millisekunden ( siehe auch:
https://medium.com/@dikrek/processor...x-fb5ab02828e2 ). Nehmen wir mal Beispielhaft 30 an. Wenn der Thread jetzt z.B. nur eine Millisekunde rechnet und Du dann Sleep aufrufst, verwirfst Du den kompletten Rest Deiner Zeitscheibe. Das bedeutet der Scheduler nimmt den von der CPU runter und er kommt frühestens nach 29 Millisekunden wieder dran. Auch wenn Du nur 5ms Schlafen willst.
Will heissen: Mit Deinen extrem kurzen Cyclen (einfache Schleifen) und aus CPU-Sicht extrem vielen und langen Wartezeiten ärgerst Du gerade mehr den Windows-Scheduler als rauszufinden was wirklich passiert
