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

Известно, что
при моделировании отражают два аспекта моделируемого объекта — структурный и динамический.
при структурном моделировании применяют "черных ящиков" и принимают решение о размерах каждого ящика и связях между ними.

при моделировании динамического аспекта можно выделить 2 подхода:

1. Математическое моделирование — когда и структура и динамика системы моделируются математически;
   
2. Моделирование, при котором структура и динамика системы моделирования в большей степени аналогична самой системе.

Пример: Моделирование потока газа: можно описывать связь между входными и выходными сигналами системы на основе диф.уравнений(1-ый подход), а можно моделировать каждую частичку газа с помощью конечного автомата, объединенного в сеть(что и делается с помощью мелкозернистого параллелизма).

Реальные примеры первого подхода думаю всем известны, а второго есть тут, тут и тут

Автор: vladpol
Дата: 11.11.05

.

Таким образом, на вопрос о степени аналогичности(похожести) моделируемой системы и моделирующей не возможно дать ответ, не зная целей моделирования. Тем не менее, мне кажется, что время отклика системы и модели должны всё-таки быть сопоставимы и когда мне приходится ждать результатов моделирования по 2 часа, а потом, немного подправив какой-то параметр модели ждать ещё 2 часа, то это плохо. Причём зависит это не только от мощности аппаратуры, но и от реализации самой модели. Согласны?

Теперь собственно проблема, которую я решаю и которая натолкнула меня на мысли, изложенные вверху.
Необходимо создать систему моделирования САУ(т.е. моделировать системы авт. управления). Затрудняюсь в выборе числа потоков в системе и механизма реализации этих потоков.

Под потоком имею в виду — различные реализации потоков управления — OS threads или fibers или lightweight process ala Erlang или самодельная кооперативная многозадачность(как, например, здесь).

Очевидно, что число потоков и механизм их реализации взаимоувязаны.

Варианты:

1. 1 UI-thread + 1 Work thread (который полностью за один "прогон" обсчитывает систему: т.е. предполагается цикл — нажали кнопку — провели все необходимые вычисления по всем отсчётам входного сигнала — нарисовали выходные графики, таблицы и т.д.)
   Большой минус — резко падает интерактивность системы, если процесс вычислений затягивается. Пользователь может захотеть увидеть промежуточные результаты и самостоятельно подкорректировать систему в процессе её работы. Т.е. это плохой подход.
   
   
2. 1 UI-thread + 1 Work thread (который по-тактово , на каждом шаге моделирования считывает текущие параметры звеньев САУ(которые задаются пользователем в UI-thread) и прогоняет текущую группу отсчётов входного сигнала через звенья). Это, на мой взгляд, промежуточный, компромиссный подход.
   
   
3. Many threads — т.е. по сути, концепция Active Object — каждому звену(моделируемому объекту) выделяем поток. Имеет ли смысл в данном случае использовать lightweight потоки и высокоуровневые средства синхронизации(взаимодействие через сообщения)) ? Или оставаться в рамках OS-threads?

Пока что изучаю опыт зарубежных коллег, хотел бы услышать Ваше мнение. На RSDN-е по теме нашёл только это

Автор: Mikl Kurkov
Дата: 05.08.06

(Моделирование на Erlang и Haskell).

Спасибо.