Я пристально изучаю основные принципы сохранения состояния исполняемой программы на диске и повторного ее возвращения. В текущем проекте, который у нас есть, каждый объект (который является вещью C-уровня со списками указателей на функции, своего рода низкоуровневой домашней ориентацией объекта - и для этого есть очень веские причины) будет вызывается для экспорта его явного состояния в записываемый и восстанавливаемый формат. Ключевое свойство этой работы заключается в том, что все состояния, связанные с объектом, действительно инкапсулированы в структурах данных объекта.
Существуют и другие решения, в которых вы работаете с активными объектами, где к некоторым объектам прикреплен поток пользовательского уровня. И, таким образом, счетчик программы, содержимое регистра и содержимое стека внезапно становятся частью состояния программы. Насколько я вижу, не существует хорошего способа сериализации таких вещей на диск в произвольный момент времени. Потоки должны парковаться самостоятельно в каком-то особом состоянии, где счетчик программ и др. Ничего не представляет, и, таким образом, в основном «сохранять» свое состояние конечного автомата выполнения в явном состоянии объекта.
Я рассмотрел ряд библиотек сериализации, и, насколько я могу судить, это универсальное свойство.
Основной вопрос такой: Или это на самом деле не так? Существуют ли решения для сохранения / восстановления, которые могут включать состояние потока, с точки зрения того, где в его коде выполняется поток?
Обратите внимание, что сохранение состояния всей системы на виртуальной машине не учитывается, то есть на самом деле это не сериализация состояния, а просто остановка машины и ее перемещение. Это очевидное решение, но в большинстве случаев оно немного тяжелое.
Некоторые вопросы прояснили, что я недостаточно ясно объяснил идею о том, как мы делаем вещи. Мы работаем над системой симуляторов, с очень строгими правилами для запуска кода внутри нее разрешено писать. В частности, мы полностью разделяем конструкцию объекта и его состояние. Указатели на функции интерфейса воссоздаются каждый раз при настройке системы и не являются частью состояния. Состояние состоит только из определенных назначенных «атрибутов», каждый из которых имеет определенную функцию get / set, которая преобразует между внутренним представлением времени выполнения и представлением хранилища. Для указателей между объектами все они преобразуются в имена. Таким образом, в нашем проекте объект может выглядеть следующим образом:
Object foo {
value1: 0xff00ff00;
value2: 0x00ffeedd;
next_guy_in_chain: bar;
}
Object bar {
next_guy_in_chain: null;
}
Связанные списки на самом деле никогда не присутствуют в структуре симуляции, каждый объект представляет какую-то аппаратную единицу.
Проблема в том, что некоторые люди хотят это делать, но также имеют потоки как способ кодирования поведения. «Поведение» здесь действительно является мутацией состояния симуляционных единиц. В основном, дизайн, который мы имеем, говорит, что все такие изменения должны быть сделаны в атомарных полных операциях, которые вызываются, выполняют свою работу и возвращаются. Все состояние хранится в объектах. У вас есть реактивная модель, или она может называться «выполнение до завершения» или «управляемый событиями».
Другой способ думать об этом состоит в том, чтобы над объектами работали активные потоки, которые находятся в вечном цикле так же, как классические потоки Unix, и никогда не завершаются. Это тот случай, когда я пытаюсь понять, может ли он быть разумно сохранен на диске, но это не представляется возможным, если не вставить виртуальную машину внизу.
Обновление, октябрь 2009 г .: Документ, связанный с этим, был опубликован на конференции FDL в 2009 г., см. этот документ о контрольных точках и SystemC.