Comments 8
Приведенный в начале стаьи пример с копрованием можно решить и без многопоточности — порты завершения ввода вывода. Да, с дополнительным потоком оно как бы проще, но UI и многопоточность очень много несут подводных камней — некоторые действия зависят от того в каком потоке вы что-то инициализировали, а в каком что-то пытаетесь рисовать.
Мое мнение — стремиться минимизировать количество потоков в программе, т.к. потоки дают весьма «простое» на первый взгляд архитектурное решение, но со временем накапливают множество потенциальных ошибок, которые произойдут в самый неподходящий момент.
Мое мнение — стремиться минимизировать количество потоков в программе, т.к. потоки дают весьма «простое» на первый взгляд архитектурное решение, но со временем накапливают множество потенциальных ошибок, которые произойдут в самый неподходящий момент.
Замените «копирование файлов» на что-нибудь другое, что необходимо реализовывать самому, без доступного асинхронного API.
Предлагаемое мной решение — как-раз таки не допускать многопоточность в UI, а изолировать рабочие потоки в движке.
Предлагаемое мной решение — как-раз таки не допускать многопоточность в UI, а изолировать рабочие потоки в движке.
Напоминает одно из прошлых решений, в котором был некоторый менеждер сообщений. В менеждер можно было складывать сообщения от разных компонент из разных потоков и подписываться на сообщения, которые обрабатывались в одном потоке.
Хотелось бы узнать мнение минусующих.
Почему данная тема не достойна того, чтобы быть на хабре?
Почему данная тема не достойна того, чтобы быть на хабре?
Я несколько раз прочитал но не понял как это работает. Можно пример как это использовать?
И не помешало бы комментарии в код
если треды совпали делаем коллбек, если нет делаем какую то околесицу…
И не помешало бы комментарии в код
if (GetCurrentThreadId() == m_clientThreadId)
{
callback();
return true;
}
else
{
m_callback = callback;
ResetEvent(m_deliveredEvent);
если треды совпали делаем коллбек, если нет делаем какую то околесицу…
Коментарии добавил, чуть позже добавлю пример использования.
Если вкратце, то объект CSyncChannel должен использоваться внутри интерфейса движка.
Движок использует канал для того, чтобы оповещать GUI о изменении своего состояния и о ошибках.
GUI подписывается на эти сообщения, используя какой-то интерфейс, вроде такого:
Движок вызывает функции GUI, используя следующую конструкцию:
Если вкратце, то объект CSyncChannel должен использоваться внутри интерфейса движка.
Движок использует канал для того, чтобы оповещать GUI о изменении своего состояния и о ошибках.
GUI подписывается на эти сообщения, используя какой-то интерфейс, вроде такого:
class IEngineEvents
{
public:
virtual void OnProgress(int progress) = 0;
virtual bool OnError(int code) = 0;
};
Движок вызывает функции GUI, используя следующую конструкцию:
IEngineEvents* listener; //указатель на объект, реализуемый GUI
syncChannel.Execute(boost::bind(&IEngineEvents::OnProgress, listener, 30));
Sign up to leave a comment.
Организация рабочих потоков: синхронизационный канал