Mehrere Threads Anhalten/Weiterführen
-
Hi, ich möchte eine längere Aufgabe damit diese die Applikation nicht zu lange blockiert in kleinere Häppchen zerlegen. Genauer gesagt soll dieser Task immer für ca. 10ms ausgeführt werden. Danach läuft die Applikation wieder für eine Zeit X weiter und anschließend wird wieder für 10 ms dieser Task ausfgeführt. Jetzt muss ich für diesen Task aber alle anderen (Worker-)Threads anhalten damit es konsistent bleibt. Leider scheint die Standard "Suspend/Resume" Logik darin zu bestehen in der Hauptschleife eines Thread ein boolsches bIsPaused Flag oder condition Variable abzufragen. D.h. aber dass der WorkerThread dann erstmal seine eigentliche Aufgabe abarbeiten muss. Wie lange das dauert kann ich nicht beeinflussen. Damit wäre aber auch die maximal angestrebte Unterbrechung von 10 ms nicht erreichbar. Denn dieser 10ms Task müsste solange warten bis alle Threads gestoppt sind worauf ich ja keinen Einfluss habe.
Unter Windows scheint es die API Funktionen ResumeThread/SuspendThread zu geben die wohl "genau das machen" was mir vorschwebt (eigentlich will ich gar nicht alle Threads stoppen sondern nur bestimmte). Aber gibt es auch unter Linux (pthreads) etwas vergleichbares mehrere Threads während ihrer Ausführung einzufrieren? Prinzipiell muss das möglich sein, denn die HardwareThreads geben den SoftwareThreads ja auch festgelegte TimeSlots in denen sie arbeiten können. Nur bietet z.B. pthreads einen äquivalenten Mechanismus nicht nach außen an. Am Ende müsste ich meine eigene Thread Klasse von Grundauf schreiben?
-
Wenn du solch verlässliches Timing wirklich brauchst, bräuchtest du ein Echtzeit-OS. Und dann könnte man weiter darüber reden, wie man das konkret machen würde.
Aber von der allgemeinen Erfahrung her, über Leute die nach so etwas fragen, und ganz speziell auch die Fragen, die du sonst stellst: Du brauchst das bestimmt nicht. Klingt schwer nach XY-Problem. Was ist dein eigentliches Vorhaben?
-
@Enumerator sagte in Mehrere Threads Anhalten/Weiterführen:
Unter Windows scheint es die API Funktionen ResumeThread/SuspendThread zu geben die wohl "genau das machen" was mir vorschwebt (eigentlich will ich gar nicht alle Threads stoppen sondern nur bestimmte). Aber gibt es auch unter Linux (pthreads) etwas vergleichbares mehrere Threads während ihrer Ausführung einzufrieren? Prinzipiell muss das möglich sein, denn die HardwareThreads geben den SoftwareThreads ja auch festgelegte TimeSlots in denen sie arbeiten können. Nur bietet z.B. pthreads einen äquivalenten Mechanismus nicht nach außen an. Am Ende müsste ich meine eigene Thread Klasse von Grundauf schreiben?
Dass Pausieren (Priorisieren) von Thread ist eigentlich eine Funktionalität, die von außen kommt, also vom Thread-Scheduler im Betriebsystemkern. Üblicherweise manipuliert man das indem man die Threadprioritäten dynamisch ändert. Es geht eigentlich über die Implementierung einer Threadklasse hinaus, also müsste ein Konstrukt sein, dass die Threads verwaltet. Also so etwas wie ein Threadpool oder eben ein Threadscheduler. Genau genommen klingt es nach einem Anwendungsszenario für Coroutinen (aka pausierbare Funktionen), aber das ist alles andere als einfach und Compilersupport dafür ist selten zu finden (ist ein spät realisiertes C++20 Feature).
@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:
Wenn du solch verlässliches Timing wirklich brauchst, bräuchtest du ein Echtzeit-OS. Und dann könnte man weiter darüber reden, wie man das konkret machen würde.
Würde ich so nicht sagen. Ein Linux mit einer 1000Hz Tickrate und aktivem HPET kann das durchaus liefern, auch ein BSD mit entsprechenden Einstellungen sollte das liefern können. Für ein Windows sehe ich da aber eher schwarz. Aber ja, stimmt schon, dass was da gemacht werden soll, klingt schon sehr nach einer RT-Geschichte, wobei 10ms ja eigentlich ein Witz sind.
-
Ich weiß nicht, ob ich nun zu einfach denke, aber ich habe Mal bei einem Thread der alles blockierte einfach ein sleep eingebaut und dann ging es.
-
@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:
Würde ich so nicht sagen. Ein Linux mit einer 1000Hz Tickrate und aktivem HPET kann das durchaus liefern, auch ein BSD mit entsprechenden Einstellungen sollte das liefern können. Für ein Windows sehe ich da aber eher schwarz. Aber ja, stimmt schon, dass was da gemacht werden soll, klingt schon sehr nach einer RT-Geschichte, wobei 10ms ja eigentlich ein Witz sind.
Können, im Sinne von die meiste Zeit klappt's, und wenn nicht, dann ruckelt das Spiel für einen Frame: Klar "können" das alle ganz ok.
Aber Können im Sinne von man muss sich drauf verlassen können, denn wenn's nicht klappt muss man das Werkstück wegwerfen, das in der angesteuerten Maschine war: Nee, lieber nicht.
Aber ich gehe davon aus, dass Enumerator eher etwas wie das erste will, und dann gibt's auch einfachere Lösungen.
-
@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:
Aber Können im Sinne von man muss sich drauf verlassen können, denn wenn's nicht klappt muss man das Werkstück wegwerfen, das in der angesteuerten Maschine war: Nee, lieber nicht.
Ja, garantiert ist es nicht. Sieht man ja bei ALSA xruns() in Verbindung mit pulseaudio oder pipewire. Aber sollte sich ja mit Linux 5.15 nun ändern. Der RT1 Patch scheint nun endlich im Mainline angekommen zu sein und damit Linux RT fähig werden.
-
@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:
Können, im Sinne von die meiste Zeit klappt's, und wenn nicht, dann ruckelt das Spiel für einen Frame: Klar "können" das alle ganz ok.
Iiih! Da reagiere ich sehr sensibel drauf wenn ich in Spielen sowas sehe, nachdem ich mal viel zu viel Zeit in einem spezialisierten Video-Renderer für eine Ausstellungs-Installation versenkt habe.
Decodiert wurden die Videos hardwarebeschleunigt via DXVA, präsentiert wurden die Frames allerdings in OpenGL. Technisch machbar, die als DirectX-Texturen vorliegenden Frames nach OpenGL zu übertragen, aber rückblickend würde ich so ein Setup nichtmal mehr mit der Kneifzange anfassen. Das lief grundsätzlich gut, bis auf dass es etwa alle 30 Sekunden einmal dazu kam, dass der Treiber bis zu 50ms brauchte, bis der Frame dann letztendlich für die Präsentation verfügbar war. Dabei gingen zwar letztendlich keine Werkstücke kaputt, aber es gibt durchaus Answendungsfälle, in denen selbst solche "Ruckler" inakzeptabel sind.
Letztendich war das mit Tricksereien lösbar, aber bei solchen Geschichten wird einem mal richtig bewusst, wie wenig man sich auf Standard-Betriebssystemen mit irgendwelchen Blackbox-Treibern darauf verlassen kann, dass Operationen zuverlässig innerhalb einer bestimmten Zeitspanne abgeschlossen werden - auch wenn das hier jetzt nicht direkt mit dem Scheduler, sondern vielmehr mit internem Treiber-Code zu tun hatte.
-
Dieser Beitrag wurde gelöscht!
-
@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:
Letztendich war das mit Tricksereien lösbar, aber bei solchen Geschichten wird einem mal richtig bewusst, wie wenig man sich auf Standard-Betriebssystemen mit irgendwelchen Blackbox-Treibern darauf verlassen kann, dass Operationen zuverlässig innerhalb einer bestimmten Zeitspanne abgeschlossen werden - auch wenn das hier jetzt nicht direkt mit dem Scheduler, sondern vielmehr mit internem Treiber-Code zu tun hatte.
Nicht zu vergessen, dass auf heutigen Rechnern unter deinem Betriebssystem Minimum noch zwei weitere laufen. Einmal 1,5 Betriebssysteme, die wir salopp UEFI nennen. Dann ein weiteres im Platform Supportcode, AGESA auf AMD und Minix auf Intel. Was genau in das AGESA eingebettet ist, ist glaub ich bis heute nicht bekannt (tippe ja auf ein RTOS). Bekannt ist, dass ab dem 80486 nen ARC Kern bei Intel drin war und dann irgendwo in der Core Familie durch einen 80586 Kern ersetzt wurde. Soll wohl dem Intel Edison sehr ähnlich sein. Bei AMD sind seither ein bis drei ARM Kerne drin. Die stecken auch in den Radeons seit der R300 (Radeon 9700 - siehe ATOM Bios). Selbst heutige einfache ARM Cortex-A Platformen haben so etwas drin. Im Fall von den Allwinner SoCs (OrangePi, ZeroPi etc) ist es ein OpenRISC 1000, auf dem ein RTOS läuft.
-
@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:
Nicht zu vergessen, dass auf heutigen Rechnern unter deinem Betriebssystem Minimum noch zwei weitere laufen.
Ja, wenn auf solchen Zwiebelschalensystemen das Timing mal zum Problem wird, wünscht man sich echt in simplere Zeiten zurück, wo es einfach daran lag, dass man selbst scheisse programmiert hat, wenns ruckelte. Und dabei mache ich nichtmal irgendwelche lowlevel-Hardwaresachen, bei denen ich eher solche Timingprobleme erwarten würde. Einfach nur flüssige Animation haben zu wollen reicht da manchmal schon aus.
Ein weiterer Störfaktor unterhalb der OS- und oberhalb der Programmebene kann übrigens auch noch der Garbage Collector bei Java-VM oder .NET-Sprachen sein. Das habe ich schon bei einigen Spielen bewundern dürfen, die z.B. in einer .NET-Sprache geschreiben wuren (z.B. mit Unity Engine). Da ist in der Standardinstallation nicht selten tatsächlich so ein "Stop-the-World"-GC aktiv der in ungünstigen Konstellationen das Spiel tatsächlich im regelmässigen Takt teilweise bis zu 2 Sekunden einfrieren lässt. Extrem nervig als Spieler - ich frage mich, ob es da keinen besseren GC gibt, der vielleicht arbeitsintensiver ist, dafür aber diskret im Hintergund arbeitet ohne alles zu stoppen.
-
@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:
Nicht zu vergessen, dass auf heutigen Rechnern unter deinem Betriebssystem Minimum noch zwei weitere laufen. Einmal 1,5 Betriebssysteme, die wir salopp UEFI nennen. Dann ein weiteres im Platform Supportcode, AGESA auf AMD und Minix auf Intel.
Also so wie ich das verstehe läuft MINIX nicht unter sondern neben dem OS. Auf eigenen Cores, die Teil des Chipset sind. Das sollte die Echtzeitfähigkeit des Haupt-Systems nicht wirklich beeinflussen.
-
@Enumerator
Auf Windows sollte ein 10ms Takt mit "soft realtime" Anforderung drin sein. Kommt halt drauf an wie viele "Aussetzer" pro Stunde man tolerieren kann. Wenn du nichtmal einen Aussetzer pro Tag tolerieren kannst, dann vermutlich eher nicht. Wenn 2-3 Aussetzer pro Stunde OK sind, dann sollte das gehen. Kommt aber wirklich auf die Hardware/Treiber an. Nur: wenn die nicht mitspielen, dann kannst du da auch mit SuspendThread & Co nix mehr machen.Und wenn Hardware & Treiber mitspielen, dann sollte es auf Windows gut reichen die Prozess- und Thread-Priorität hochzusetzen.
Auf Linux: keine Ahnung. Die "niceness" funktioniert ganz anders als die relativ harten Thread-Prioritäten von Windows.
-
@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:
Ein weiterer Störfaktor unterhalb der OS- und oberhalb der Programmebene kann übrigens auch noch der Garbage Collector bei Java-VM oder .NET-Sprachen sein. Das habe ich schon bei einigen Spielen bewundern dürfen, die z.B. in einer .NET-Sprache geschreiben wuren (z.B. mit Unity Engine). Da ist in der Standardinstallation nicht selten tatsächlich so ein "Stop-the-World"-GC aktiv der in ungünstigen Konstellationen das Spiel tatsächlich im regelmässigen Takt teilweise bis zu 2 Sekunden einfrieren lässt.
Ohhh ja, ich erkläre seit Jahrzenten, dass Sprachen mit einem GC ganz nett sind, aber für Anwendungen, wo es auf relativ genaues Timing ankommt, absolutes Gift sind. Du weißt einfach nie, wann ein GC loslegt und dann irgendwo Bandbreite im RAM oder CPU Zeit frisst, die du gerade feindosiert brauchst. Wohl gemerkt, Sprachen bei denen man wenig bis keine Kontrolle über den GC hat. "Ja aber Akiko, du hast so dafür keine Memoryleaks!" Wowowow ... dann schau doch mal das tolle Spiel Oxygen not Included an. Lade einen 300+ Runden Spielestand etwa 50 mal. Wenn dann das Spiel noch unter 64 GB RAM frisst, haste Glück gehabt.
Extrem nervig als Spieler - ich frage mich, ob es da keinen besseren GC gibt, der vielleicht arbeitsintensiver ist, dafür aber diskret im Hintergund arbeitet ohne alles zu stoppen.
Da bin ich mir nicht sicher. Theoretisch hat man es besser im Griff in Sprachen wo man den GC instruieren kann, sprich den GC anweisen kann, wann und wie lange er aufräumen darf. Eine der besten Lösungen ist aber nach wie vor das RAII, wie man es in C++ und Ada direkt steuern kann, oder in funktionalen Sprachen wie R oder ML bzw in modernen Sprachen wie Rust implizit hat. Sprich ein Freigeben von Speicher findet immer dann statt, wenn ein Objekt abgebaut wird, und dass ist etwas was man relativ gut kontrollieren kann.
@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:
Also so wie ich das verstehe läuft MINIX nicht unter sondern neben dem OS. Auf eigenen Cores, die Teil des Chipset sind. Das sollte die Echtzeitfähigkeit des Haupt-Systems nicht wirklich beeinflussen.
Ja okay, ist wohl irgendwo eine Interpretationsfrage. Also ich definiere "unter" als völlig transparent zum Hauptbetriebssystem. Oder man kann auch schauen, wer bekommt Priorität beim Zugriff auf die Hardware (Remotezugriff auf Managementsysteme)
Habe ich auch immer gedacht, dass es nichts ausmach, bis ich an einem embedded Systemen gearbeitet habe, dass 24/7 kontinuierlich 96kHz/18Bit/8 Kanäle und parallel dazu drei Serialport Streams (2x 115200, 1x 19200 Baud) Signalanalyse gemacht hat. Da gabs eine leichte Varianz bei der PCI Latenz und die wurde von einem dieser Betriebssysteme im Platform Supportcode verursacht.
-
@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:
Ja okay, ist wohl irgendwo eine Interpretationsfrage. Also ich definiere "unter" als völlig transparent zum Hauptbetriebssystem. Oder man kann auch schauen, wer bekommt Priorität beim Zugriff auf die Hardware (Remotezugriff auf Managementsysteme)
Ja, verstehe. Ich hab "unter" halt im Sinn von einem Hypervisor interpretert, und so ist es eben soweit ich weiss nicht.
Habe ich auch immer gedacht, dass es nichts ausmach, bis ich an einem embedded Systemen gearbeitet habe, dass 24/7 kontinuierlich 96kHz/18Bit/8 Kanäle und parallel dazu drei Serialport Streams (2x 115200, 1x 19200 Baud) Signalanalyse gemacht hat. Da gabs eine leichte Varianz bei der PCI Latenz und die wurde von einem dieser Betriebssysteme im Platform Supportcode verursacht.
Interessant!
Aber natürlich muss das Management-System irgendwie Zugriff auf die Hardware haben, es soll sie ja schliesslich überwachen. D.h. leichte Timing-Unterschiede auf diversen Bussen etc. werden leider nicht zu vermeiden sein. Ausser wenn man das Management-System abdreht - wenn es sich denn abdrehen lässt.Ich finde diese Management-System auch grundsätzlich ziemlich cool. Wenn man so richtig viele (physikalische) Server hat, ist man schon froh, wenn man einfach nur in einem Admin-Tool klicksi machen muss und damit z.B. einen Server der hängt "hart" rebooten kann. Oder ausschalten/einschalten/was auch immer man braucht. Blöd ist nur wenn sie sich eben nicht abdrehen lassen, und dann (wenn auch nur geringfügig) das System stören. Oder natürlich wenn sie Sicherheitslücken in z.B. ihrem Netzwerk-Stack haben.
-
@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:
@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:
Ja okay, ist wohl irgendwo eine Interpretationsfrage. Also ich definiere "unter" als völlig transparent zum Hauptbetriebssystem. Oder man kann auch schauen, wer bekommt Priorität beim Zugriff auf die Hardware (Remotezugriff auf Managementsysteme)
Ja, verstehe. Ich hab "unter" halt im Sinn von einem Hypervisor interpretert, und so ist es eben soweit ich weiss nicht.
Wobei es einen Hypervisor ja nicht ausschließt, ein guter Hypervisor wird auch von dem darin laufenden Betriebssystem nicht bemerkt. Pass auf, es wird noch unangenehmer. Wenn man baremetal programming macht oder eben Betriebssysteme/Bootloader schreibt, arbeitet man ja mit den verschiedenen Hardwarezugriffsleveln der CPU. Bei x86 wäre das Ring 0 bis 3, beim m68k usermode und supervisormode, bei ARM usermode, kernelmode und trustzone/trusted mode und so weiter. Dadurch dass Intel einige ihrer Platform Supportcode Geschichten ja so dermaßen vergeigt haben, dass da mehrere kritische Updates nötig waren und einige Entwickler die ganze Geschichte anfangen konnten zu reverse-engineeren (siehe Coreboot/Libreboot, die können den Platform Supportcode teilweise ersetzen/deaktivieren), kam raus, dass x86 CPUs in der Tat noch einen Ring -1 bis Ring -3 haben. Es war viele Jahre lang unbekannt. Dies ist nicht nur gruselig, es ist im höchsten Maße bedenklich. Man kann vor allem diese Accesslevel nicht in den Bitmasken in den global describer tables setzen und irgendwie nutzen. Falls du dich fragst wo das Verwendung findet. Die Virtualisierungshardware Vanderpool (Intel) und Pacifica (AMD) sind keine reine Hardwarelösung, sondern ein Hypervisor, der im Ring -1 läuft. Im Ring -2 läuft die Systemmanagementsoftware und Ring -3 ist nicht mal die eigentlich x86 CPU, sondern der eingebettete Kern (ARC oder 80586) der seine Geschichten macht. Ist jedenfalls mein aktueller Kentnissstand. Im Großen und Ganzen hast du erstaunlich wenig Kontrolle über deine x86 Hardware. Bei ARM ist es zum Beispiel nicht ganz so schmlimm. Auf Github findest du die ARM Trusted Firmware, welche die Software ist, die in der Trustzone läuft. Ist allerdings nicht bei jedem ARM so realsiert (RPi zum Beispiel, der ist mehr locked-down als andere ARM Lösungen).
Habe ich auch immer gedacht, dass es nichts ausmach, bis ich an einem embedded Systemen gearbeitet habe, dass 24/7 kontinuierlich 96kHz/18Bit/8 Kanäle und parallel dazu drei Serialport Streams (2x 115200, 1x 19200 Baud) Signalanalyse gemacht hat. Da gabs eine leichte Varianz bei der PCI Latenz und die wurde von einem dieser Betriebssysteme im Platform Supportcode verursacht.
Interessant!
Aber natürlich muss das Management-System irgendwie Zugriff auf die Hardware haben, es soll sie ja schliesslich überwachen. D.h. leichte Timing-Unterschiede auf diversen Bussen etc. werden leider nicht zu vermeiden sein. Ausser wenn man das Management-System abdreht - wenn es sich denn abdrehen lässt.Genau das ist der Punk, man kann es nicht 100% abdrehen. Ohne das funktionieren heutige (x86) CPUs einfach nicht mehr.
Ich finde diese Management-System auch grundsätzlich ziemlich cool. Wenn man so richtig viele (physikalische) Server hat, ist man schon froh, wenn man einfach nur in einem Admin-Tool klicksi machen muss und damit z.B. einen Server der hängt "hart" rebooten kann. Oder ausschalten/einschalten/was auch immer man braucht. Blöd ist nur wenn sie sich eben nicht abdrehen lassen, und dann (wenn auch nur geringfügig) das System stören. Oder natürlich wenn sie Sicherheitslücken in z.B. ihrem Netzwerk-Stack haben.
Ja, in Servern bzw remote-managed Firmen-Workstations macht es wirklich Sinn, aber nicht in jeder normalen Desktop Hardware. Das ist ja einer der Gründe warum die freie Software unter Stallman entstanden ist. Damals gab es schon Bestreben in diese Richtung und Stallman hat regelrecht vorausgesehen wohin es in Zukunft (heute) führen wird.
-
@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:
kam raus, dass x86 CPUs in der Tat noch einen Ring -1 bis Ring -3 haben. Es war viele Jahre lang unbekannt. Dies ist nicht nur gruselig, es ist im höchsten Maße bedenklich. Man kann vor allem diese Accesslevel nicht in den Bitmasken in den global describer tables setzen und irgendwie nutzen. Falls du dich fragst wo das Verwendung findet. Die Virtualisierungshardware Vanderpool (Intel) und Pacifica (AMD) sind keine reine Hardwarelösung, sondern ein Hypervisor, der im Ring -1 läuft. Im Ring -2 läuft die Systemmanagementsoftware und Ring -3 ist nicht mal die eigentlich x86 CPU, sondern der eingebettete Kern (ARC oder 80586) der seine Geschichten macht.
Naja... die Grenzen sind da ein bisschen verschwommen denke ich. Also was ist eine "reine Hardwarelösung" und was nicht?
Schon CPUs wie der 6502 haben ein Instruction-ROM über das eine Instruction in mehrere Teile aufgesplittet wird. Ist das noch rein Hardware, weil's ein ROM ist? Spätere CPUs haben dann Microcode, was im Prinzip auch nix anderes ist bzw. nur eine konsequente fortführung des selbem Prinzips. Ist das noch rein Hardware? Was wenn man den Microcode updaten kann? Dann ist es kein ROM mehr? Immer noch rein Hardware? Und spätestens wenn man Virtualisierung in irgendeiner Form implementieren möchte, was schon bei einer MMU anfängt, werden die Dinge die zum Abarbeiten von einfachen Instruktionen oder auch nur Speicherzugriffen nötig sind ziemlich komplex. Da kann es schon Sinn machen das nicht mehr alles über klassischen Microcode zu machen sondern eine Abstraktionsebene darüber anzusetzen - nur halt mit Code der nicht vom OS kommt sondern quasi direkt in die CPU mit eingebaut ist. Bzw. aus dem UEFIA/BIOS kommt (AGESA & Co).
Und dass die Chip-Hersteller das nicht open-sourcen wollen ist denke ich auch klar, es würde ja viel darüber verraten wie diese Features in ihren CPUs umgesetzt sind.
Genau das ist der Punk, man kann es nicht 100% abdrehen. Ohne das funktionieren heutige (x86) CPUs einfach nicht mehr.
Bist du sicher was den 2. Punkt angeht? Ich hätte angenommen dass moderne x86 CPUs problemlos ohne dieses Management-OS im PCH/Chipset/... auskommen.
-
@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:
dann schau doch mal das tolle Spiel Oxygen not Included an. Lade einen 300+ Runden Spielestand etwa 50 mal. Wenn dann das Spiel noch unter 64 GB RAM frisst, haste Glück gehabt.
Lustig, das ist exakt eines der Spiele, wo mir der GC ebenfalls negativ aufgfallen ist. Es kommt nicht immer vor, aber bei manchen fortgeschrittenen Spielständen kommt es manchmal zu diesen regelmässigen Sekunden-Aussetzern alle paar Sekunden. Das ist extrem nervig. Das Ruckeln an sich ist nicht ganz so wild, sondern vor allem dass es oft dazu führt, dass man letztendlich wegen dem Aussetzer bei einer komplexen Maschine an eine falsche Stelle klickt und sich dabei schonmal gehörig was kaputt macht, wenn nach dem Fehlklick giftiges heißes Gas oder flüssige Lava in die Basis strömen
... es gibt da noch ein anderes Spiel namens "Eco" bei dem sich die UI-Programmierung hervorragend mit den GC-Aussetzern ergänzt: Das Spiel registriert zuerst (auch während einer GC-Pause) dass ein Mausklick stattgefunden hat, dann spielt eine kurze "Aktions-Animation" und erst wenn diese durchgelaufen ist, wird die eigentliche Position bestimmt, an die man geklickt hat. Da veklickt man sich ohnehin schon oft genug, aber wenn dazwischen auch noch so eine GC-Pause liegt, haut man sich regelmässig irgendwelche wichtigen Sachen kaputt... aber sind ja zum Glück nur Spiele - mag mir gar nicht ausmalen, wenn man sowas bei einem Programm hat, mit dem man tatsächlich Schaden anrichten kann. Stelle mir gerade eine Steuersoftware für einen Chirurgieroboter vor, bei der man sich regelmässig wegen dem GC "verklickt" 
-
@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:
mag mir gar nicht ausmalen, wenn man sowas bei einem Programm hat, mit dem man tatsächlich Schaden anrichten kann. Stelle mir gerade eine Steuersoftware für einen Chirurgieroboter vor, bei der man sich regelmässig wegen dem GC "verklickt"
Was wir denken wie es ist: Die haben da eine professionelle Echtzeitumgebung, intensiv getestet, Hardware und Software optimal abgestimmt.
Wie es wirklich ist: Programm läuft unter Windows 95, macht einfach überhaupt keine Speicherfreigaben, und wird daher 1x die Stunde neu gestartet bevor der Speicher voll läuft
-
@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:
Wie es wirklich ist: Programm läuft unter Windows 95, macht einfach überhaupt keine Speicherfreigaben, und wird daher 1x die Stunde neu gestartet bevor der Speicher voll läuft
Noch eine Stufe darunter mit DOS wäre vielleicht gar nicht mal so verkehrt, wenn man nun wirklich nichts besseres zur Verfügung hat. Unter dem System haben Programme so viel Kontrolle, das ist fast wie direkt in das Programm als eigenes OS booten. Damit lassen sich Echtzeitanforderungen sicherlich recht gut erfüllen - wenn auch ziemlich fummelig, weil das OS halt generell nicht sonderlich viel kann
Was mir an DOS immer gut gefallen hat ist, dass man damit Dinge stricken kann, die sonst nur gehen, wenn man ein eigenes OS baut - ohne den Aufwand tatsächlich ein eigenes OS programmieren zu müssen.
-
@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:
Ein weiterer Störfaktor unterhalb der OS- und oberhalb der Programmebene kann übrigens auch noch der Garbage Collector bei Java-VM oder .NET-Sprachen sein. Das habe ich schon bei einigen Spielen bewundern dürfen, die z.B. in einer .NET-Sprache geschreiben wuren (z.B. mit Unity Engine).
Ist etwas OT, aber permanent Objekte löschen oder erstellen sollte man in Spielen eh nicht. Die werden gepoolt (oder wie auch immer das deutsche Verb zu Object-pooling ist), also zu Beginn erstellt und dann ein/aus geblendet und das macht man auch z.B. in der Unreal-Engine (c++).
