По тексту
Раздел 1.
1 Я подозреваю, что далеко не все читатели рассылки поймут, что ты имеешь ввиду под моделью, что -- под процессором, и что процессора -- это на самом деле модель. Поэтому было бы неплохо в разделе "Задачи нового монитора" описать все его задачи -- всё равно этот документ, скорее всего, превратится в документацию по монитору.
2 Стоит разделить требования на требования к монитору как таковому (обеспечение псевдопараллельного выполнения и синхронизации нескольких моделей) и требования к моделям (механизм откатов, наличие которого предполагает монитор).
3 Требование динамической конфигурации -- здесь имеется ввиду динамическое добавление моделей в работающую систему? В ММ-программе это просто невозможно. Или имеется ввиду что-то ещё?
4 Если я правильно понял последующий текст, то предполагается, что монитор мало что знает о том, как устроены модели (т.е. они для него -- чёрные ящики). Тогда, наверное, последний пункт требований тоже относится скорее к возможностям описания моделей, чем к монитору.
5 Не понятно, почему реактивные модели противопоставлены моделям с отдельным потоком управления -- это вроде бы ортогональные вещи. Конкретизируй, что имеется ввиду.
3.1
1. "В процессе обработки модель может взаимодействовать с другими моделями" Мне кажется, что на этом уровне уже нужно конкретизировать, какое взаимодействие имеется ввиду. Т.е. описать доступные моделям средства взаимодействия помимо монитора.
2. А что, если вместо public-интерфейса simulate() + simulate_until + backtrace() использовать simulate(from,to)? Если передаётся from, меньшее текущего времени, то процесс выполняет backtrace, или что он там умеет.
3.2
1. "Например, процессу может быть послано почти одновременно несколько прерываний, и все их нужно хранить." Может ли возникнуть такая ситуация в описанной схеме работы монитора? Вроде бы нужно хранить только прерывание с минимальным временем доставки.
3.3
1. Не понятно, откуда будет браться информация о задержках на передачу сообщений/прерываний. Эти задержки не должны быть вшиты в модели (потому что могут зависеть от компоновки моделей). Нужно предусмотреть механизм из задания на уровне описания связей между моделями.
3.4 и 3.5 Я не совсем понял разницу между пассивным получателем и активным получателем с блокирующим приёмом. Похоже, что пассивный получатель -- лишняя сущность, и рассматривать нужно просто различные типы синхронизации при передаче и приёме сообщений. Здесь же возникает вопрос -- а как задаются привязки точек синхронизации (=посылки и приёма сообщений)? Для того, чтобы модель была масштабируемой, нужен какой-то гибкий способ это делать.
Как в этой схеме будут моделироваться буфера? Ведь при записи сообщения в буфер выполнения оператора "приём" не происходит. иногда бывает полезно уметь поддерживать буфер как примитив среды моделирования, потому что моделирование буфера отдельным процессом делает простую, в общем-то, модель, довольно громоздкой.
При отправке сообщения одновременно нескольким адресатам возникнет ситуация, когда в очереди процессов появляется несколько одновременных событий. Нужно решить, как с ней справляться.
Если событие может быть действием, т.е. связывать два процесса, то м.б. драйверу полезно знать не только время сл. события модели, но и то, на какую модель это событий повлияет. Например, если в очереди есть два события с одинаковым временем, то зная информацию об объектах действий можно правильно выбрать следующий процесс.
Костя.