Ich untersuche die Grundprinzipien des Speicherns des Status eines ausführenden Programms auf der Festplatte und das erneute Einspielen. In dem aktuellen Design, das wir haben, wird jedes Objekt (welches ein C-Level-Ding mit Funktionszeigerlisten ist, eine Art von Low-Level-home-made-Objektorientierung - und es gibt sehr gute Gründe, dies auf diese Weise zu tun) aufgerufen, um den expliziten Status in ein beschreibbares und wiederherstellbares Format zu exportieren. Die Schlüsseleigenschaft, um dies zum Laufen zu bringen, besteht darin, dass alle zu einem Objekt gehörenden Zustände tatsächlich in den Objektdatenstrukturen eingekapselt sind.Serialisierung von Objekten: kein Thread-Status kann beteiligt sein, oder?
Es gibt andere Lösungen, wo Sie mit aktiven Objekten arbeiten, wo ein Thread auf Benutzerebene an einige Objekte angehängt ist. Und so werden der Programmzähler, der Registerinhalt und der Stapelinhalt plötzlich Teil des Programmzustandes. Soweit ich sehen kann, gibt es keine gute Möglichkeit, solche Dinge zu einem beliebigen Zeitpunkt auf die Festplatte zu serialisieren. Die Threads müssen sich in einem speziellen Zustand ablegen, in dem nichts vom Programmzähler und anderen repräsentiert wird, und somit ihren Ausführungsstatus-Maschinenzustand im Wesentlichen in den expliziten Objektzustand "speichern".
Ich habe eine Reihe von Serialisierungsbibliotheken angeschaut, und soweit ich das beurteilen kann, ist dies eine universelle Eigenschaft.
Die Kernfrage ist dies: Oder ist das eigentlich nicht so? Gibt es da draußen Lösungen zum Speichern/Wiederherstellen, die einen Thread-Status enthalten können, in Bezug darauf, wo in seinem Code ein Thread ausgeführt wird?
Beachten Sie, dass das Speichern eines gesamten Systemstatus in einer virtuellen Maschine nicht zählt, das heißt nicht wirklich den Zustand serialisiert, sondern nur eine Maschine einfriert und verschiebt. Es ist eine offensichtliche Lösung, aber ein bisschen Schwergewicht die meiste Zeit.
Einige Fragen machten deutlich, dass ich nicht klar genug war, um die Idee zu erklären, wie wir die Dinge machen. Wir arbeiten an einem Simulatorsystem, mit sehr strengen Regeln für den Code, der darin ausgeführt werden darf. Insbesondere machen wir eine vollständige Trennung zwischen Objektkonstruktion und Objektstatus. Die Schnittstellenfunktionszeiger werden jedes Mal neu erstellt, wenn Sie das System einrichten, und sind nicht Teil des Status. Der Zustand besteht nur aus bestimmten festgelegten "Attributen", die jeweils eine definierte Get/Set-Funktion haben, die zwischen interner Laufzeitdarstellung und Speicherdarstellung umsetzt. Für Zeiger zwischen Objekten werden sie alle in Namen konvertiert. Also in unserem Design könnte ein Objekt kommen, wie dies in der Lagerung:
Object foo {
value1: 0xff00ff00;
value2: 0x00ffeedd;
next_guy_in_chain: bar;
}
Object bar {
next_guy_in_chain: null;
}
Verknüpfte Listen sind nie wirklich in der Simulationsstruktur stellt jedes Objekt eine Einheit von Hardware irgendeine Art.
Das Problem ist, dass einige Leute dies tun möchten, aber auch Threads als eine Möglichkeit haben, Verhalten zu codieren. "Verhalten" ist hier wirklich eine Mutation des Zustandes der Simulationseinheiten. Grundsätzlich besagt das Design, dass solche Änderungen in atomaren vollständigen Operationen gemacht werden müssen, die aufgerufen werden, ihre Arbeit machen und zurückkehren. Der gesamte Status ist in den Objekten gespeichert. Sie haben ein reaktives Modell, oder es könnte "Lauf bis zur Fertigstellung" oder "ereignisgesteuert" heißen. Die andere Art darüber nachzudenken besteht darin, dass Objekte aktive Threads haben, die an ihnen arbeiten, die wie klassische Unix-Threads in einer ewigen Schleife sitzen und niemals terminieren. Dies ist der Fall, wenn ich versuche zu sehen, ob es vernünftig auf der Festplatte gespeichert werden kann, aber es scheint nicht möglich zu sein, ohne eine darunterliegende VM dazwischenzusetzen.
Update, Oktober 2009: Ein diesbezügliches Dokument wurde 2009 auf der FDL-Konferenz veröffentlicht, siehe this paper über Checkpointing und SystemC.
Nun, die Fäden hier sind Dinge in der Sache namens SystemC, im Grunde kooperative nicht preemptive Threading mit Quickthreads oder Windows-Fasern. In einem einzelnen Betriebssystem-Thread. – jakobengblom2