Добрый день,
примерно три года назад было такое сообщение
MVC и синхронизация потоковАвтор: AndreyFedotov
Дата: 01.07.04
.
Тогда посоветовали посмотреть в сторону использования СУБД или перенятия методов синхронизации из мира СУБД. Конкретно предложили задать вопрос на форуме БД, что
я и сделалАвтор: Didro
Дата: 21.08.07
. Литературу мне подсказали, изучаю. Но видимо, поскольку вопрос больше архитектурный, то конкретных ответов не дали. (это типа я прошу не считать данное сообщение за кросспостинг
)
Есть
ряд похожих задачАвтор: Didro
Дата: 21.08.07
. Моя задача одна из них:
Есть конкретная задача, которая как паттерн присуща системам моделирования: её можно назвать "многопоточный MVC".
конкретизирую под системы моделирования, того вида, которым занимаюсь:
Есть объекты(акторы) имеют входные\выходные порты, реализуют определенный мат.оператор над множеством этих портов (сложение, интегрирование, преобразование Фурье(FFT) и т.д.). Модель в целом состоит из таких объектов, связанных в граф. Вершины графа — акторы, дуги соединяют порты акторов.
//актор инкремент увеличивает значение, пришедшее во входящий порт, на значение параметра и пересылает увеличенное значение дальше
class Incrementer: IActor
{
public double param{get;set;}
public void Fire(){output_port.SendData(input_port.GetData()+param)};
}
Есть своеобразный планировщик (реализующий кооперативную многозадачность среди акторов):
//выдает такт времени каждому актору, обходя граф
class Sheduler
{
//в собственном потоке планировщика
void HisOwnThread()
{
while(!program_end)
{
foreach(IActor actor in graph)
actor.Fire();
}
}
}
Есть GUI-поток, в котором пользователь создает объекты, строит граф из этих объектов, запускает планировщик и далее при
запущенном(sic!) планировщике может изменять граф или менять параметры объектов. В совсем хорошей системе планировщиков может быть много — например, мы хотим какой-либо объект поместить в собственный поток, чтоб он там слушал сетевой порт. Тогда мы для этого объекта создадим собственный планировщик (у этого планировщика будет свой поток). Значит, у нас будет 2 планировщика, значит, нужна будет иерархия планировщик (есть, конечно, и другие варианты).
Теперь вопрос: как впихнуть это в БД? Или даже так использовать ли БД? Основная цель использования БД — упростить синхронизацию потоков. И есть ли БД, которые подходят для такой задачи? (подождите отвечать, ниже приведен текущий вариант решения
)
Если использовать БД, то я вижу один способ — поместить данные о графе и параметрах в БД. Тогда программа претерпит такие изменения:
class Incrementer: IActor
{
public double param{get {query("select Incrementer.param from DB");}}
public void Fire(){output_port.SendData(input_port.GetData()+param)};//тут идет обращение к БД, чтоб знать по какой дуге послать данные
}
class Sheduler
{
//в собственном потоке планировщика
void HisOwnThread()
{
while(!program_end)
{
graph=BuildNewGraphVersion_form_DataBase();
foreach(IActor actor in graph)
actor.Fire();
}
}
}
Думаю тут можно будет прикрутить кэширование, оповещение об изменениях и т.д. Возможно pLINQ(parallelLinq) будет решением этой проблемы, но пока решения не видно и подходящей БД тоже.
Если не использовать БД, то мое текущее решение описано
здесьАвтор: Didro
Дата: 22.08.07
.
Что мне не нравиться в моем текущем решении:
Велосипедность решения — по сути дела создано собственное объектное хранилище данных и собственный язык запросов
Не гибкость и не типизируемость языка запросов (да, знаю, можно создать DSL, но это ещё один велосипед).
Постоянное раздутие интерпретатора запросов, из-за не универсальности хранилища данных. Так, например, сейчас все параметры и все порты акторов имеют тип double, теперь хочу добавить актор FFT, он на выходе должен выдавать complex — проблема — нужно переделывать всю систему. Или, например, хочу параметру добавить поля: отображаемое имя, видим\невидим в GUI, редактируемый из GUI или нет и прочее, опять же нужно переписывать базовые классы системы. в PtolemyII(см.ниже) это решено за счет тотального полиморфизма (через наследование реализаций), в принципе, конечно, можно и поэтому пути пойти.
Почему изначально не стал использовать БД:
нету опыта, системы моделирования, с которыми я знаком, не используют БД:
Сейчас я ориентировался на архитектуру таких систем как PtolemyII(Беркли) и МВТУ(МГТУ им. Баумана). В этих системах БД не используется, также БД не используется в single-player играх (не сетевых тобишь), а такой вид игр очень напоминает системы моделирования. Причины этого, если честно, мне не очень понятны.
Очень надеюсь на советы или "руководящие вопросы", букв много, ну дак форум такой
Спасибо.
p.s.
ответ на вопрос "зачем мне вообще нужны потоки в такой системе"
здесьАвтор: Didro
Дата: 28.02.07
. Если кратко — для придания системе большей интерактивности, чтоб моделирование происходило как в реальном времени.