On Mon, 12 Dec 2005, Vladimir Prus wrote:

Господа, как некоторые из вас возможно знают, для проекта "NM Model" имеется план написать новый монитор событийного моделирования. В приложении -- первые наброски схему его работы.

Комментарии были бы очень полезны.

Всем доброго времени суток.

Несколько предварительных замечаний: 1. В ЛВК был разработан еще один монитор, основными свойствами которого по выражению автора должны были быть "динамизм" и переносимость. Монитор "runenv", cvs:netedit/runenv Автор П. Шугалев. Монитор вполне успешно применялся для моделирования. В некоторой степени он может быть свободен от приведенных Володей недостатков.

2. Для монитора "runmon" должен быть некий документ, в котором описаны требования к нему, а также основные его свойства и концепции. Мы его достаточно долго обсуждали, у Никиты он где-то должен быть. Как минимум, стоит его посмотреть чтобы взять полезные идеи.

3. По поводу невозможности использовать монитор Сухого проекта (rtms). В том виде, в котором он сейчас - вероятно нет. Но почему бы его не доработать ? Почему это полезно и почему это возможно: Это единственный монитор, который в каком-то виде поддерживает моделирование в реальном времени, синхронизацию модельного времени с реальным и т.д. Эта функциональность востребована и будет развиваться на базе этого монитора в дальнейшем.

Никита некоторое время назад говорил о необходимости (и возможности) разработать некоторый общий унифицированный монитор прогона, который бы положил конец многообразию сред прогона в ЛВК (и, как следствие, трудности или невозможности их сопровождать).

Возможно, следует двигаться в этом направлении, в отличии от: > для проекта "NM Model" имеется план написать новый монитор событийного моделирования

Максим

По тексту

Раздел 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 Я не совсем понял разницу между пассивным получателем и активным получателем с блокирующим приёмом. Похоже, что пассивный получатель -- лишняя сущность, и рассматривать нужно просто различные типы синхронизации при передаче и приёме сообщений. Здесь же возникает вопрос -- а как задаются привязки точек синхронизации (=посылки и приёма сообщений)? Для того, чтобы модель была масштабируемой, нужен какой-то гибкий способ это делать.

Как в этой схеме будут моделироваться буфера? Ведь при записи сообщения в буфер выполнения оператора "приём" не происходит. иногда бывает полезно уметь поддерживать буфер как примитив среды моделирования, потому что моделирование буфера отдельным процессом делает простую, в общем-то, модель, довольно громоздкой.

При отправке сообщения одновременно нескольким адресатам возникнет ситуация, когда в очереди процессов появляется несколько одновременных событий. Нужно решить, как с ней справляться.

Если событие может быть действием, т.е. связывать два процесса, то м.б. драйверу полезно знать не только время сл. события модели, но и то, на какую модель это событий повлияет. Например, если в очереди есть два события с одинаковым временем, то зная информацию об объектах действий можно правильно выбрать следующий процесс.

Костя.