crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

> Менеджер задач, Архитектура паттерна Команда в различных режимах работы
saxon
  опции профиля:
сообщение 14.4.2011, 11:04
Сообщение #1


Новичок


Группа: Новичок
Сообщений: 7
Регистрация: 14.4.2011
Пользователь №: 2601

Спасибо сказали: 0 раз(а)




Репутация:   0  


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

программка имеет некий функционал, который условно можно поделить на мгновенно выполняемый и долго выполняемый.
При выполнении любой команды можно прямо на месте (тут 2 подзадачи: во время компиляции / в рантайме) определить, в каком режиме будет выполняться работа (асинхронно в потоке или синхронно).
Асинхронные задачи могут быть приостановлены или отменены. Также команда может иметь прогресс (а может не иметь). И напоследок они могут быть отменяемыми.
Вот и все условия задачки.

Как я вижу решение задачи и какие есть в связи с этим трудности.
1. Команда — реализация одноименного паттерна. Она всегда выполняется синхронно.
— как можно не по ГоФ реализовать возможность отката команды? Не хочется добавлять методы туда, где их не должно быть. Как по мне, лучше проверять на поддерживаемость интерфейса что-то вроде dynamic_cast< IUndoable * >()

2. Менеджер асинхронных задач хранит массив объектов JobThread. Ни приоритетов, ни зависимостей между потоками нет.
что-то вроде такого:
class Thread: public boost::noncopyable
{
public:
Thread( Model::IThreadObserver &observer );

public:
void Start( boost::shared_ptr< IRunnable > job );

private:
static void ThreadFunction( Thread *jobThread );


private:
Model::IThreadObserver &m_observer;
boost::shared_ptr< Model::IRunnable > m_job;
boost::scoped_ptr< boost::thread > m_thread;

};

— как реализовать приостановку и остановку выполнения потока (не убивая его). в потоке постоянно проверять, не нужно ли отмениться или остановиться?

3. Обработка результатов. Хочется прикрутить буст::сигналы для обработки состояния. но пока не придумал как.
при создании команды ей передается слот, к которому она подключится и который будет обрабатывать все ее события. Не зависимо от того, является ли команда синхронной или асинхронной.
— что почитать по этому поводу?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
 
Начать новую тему
Ответов (1 - 1)
Iron Bug
  опции профиля:
сообщение 14.4.2011, 11:52
Сообщение #2


Профессионал
*****

Группа: Модератор
Сообщений: 1611
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 219 раз(а)




Репутация:   12  


приостановка потока - только через проверку изнутри потока. иначе поток может залочиться в состоянии, когда идёт обращение к общим ресурсам системы и подвесить всех. собственно, даже в стандарте POSIX нет приостановки потоков. в бусте есть механизм отложенного запуска потоков. если не хочется убивать поток, нужно организовывать внутренний цикл, который будет выполняться и приостанавливаться по каким-то внешним событиям.
собственно про буст можно читать только документацию буст и примеры, которые с ним поставляются. редко требуется что-то ещё.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 29.3.2024, 2:32