UI vs многопоточность
От: mjau  
Дата: 18.03.09 07:08
Оценка:
Привет All

назрел фундаментальный вопрос, который, к содалению, весьма мало где освещается, даже правильнее сказать, за полдня поиска я не нашел, где он хорошо освещается вовсе.
Предположим, у нас есть некий кастомный UI контрол, например, список на основе ListCtrl в режиме ownerdata плюс некий контейнер для данных плюс API для доступа к этим данным.
И есть отдельный поток, который через API диалога, содержащего этот контрол, к нему обращается.
Соответственно, вопросы:
1. Как я понимаю, а ATL/WTL никаких механизмов синхронизации потоком с обработкой сообщений, кроме того, что предоставляе SendMessage нет. Поэтому, насколько правильно будет синхронизировать доступ только к контейнеру данных листконтрола, покаав наружу "прямой" API для доступа к нему? При этом придется следить, чтобы в залоченных кусках не было обращений к самому списку и прочим SendMessage. Есть ли при этом какие-нибудь подводные камни, например, контрол начинает отрисовываться с одним набором данных, и заканчивает уже с другим набором, и как их можно избежать?
2. Является ли более "идеологически правильным" весь внешний API контрола заворачивать при помощи SendMessage()/add message handler, сваливая всю работу по синхронизаии на нее? Почему в таком случае, в некоторых WTL котролах наружу торчит незавернутый API, и как предполагается решать вопрос с синхронизацией там?
Каждый, просыпаясь утром, должен задавать себе вопрос — что он может сегодня сделать, чтобы россиянства
Автор: Kerk
Дата: 21.08.22
в мире стало меньше.
Re: UI vs многопоточность
От: c-smile Канада http://terrainformatica.com
Дата: 23.03.09 06:42
Оценка:
Здравствуйте, mjau, Вы писали:

"GUI is inherently single threaded" весчь ибо карточка графическая — 1 шт., клавиатура — 1 шт. и мышка тоже — 1 шт.

Рабочие потоки напрямую к GUI обращаться в общем случае не должны. Собственно поэтому в WTL и нет сихронизации никакой.
Ибо как бы не ясно что делать системе исполняющей скажем BitBlt когда кто-то в ту bitmap из другого потока пишет.
Re: UI vs многопоточность
От: tonykent  
Дата: 23.05.09 19:06
Оценка: +1
M>2. Является ли более "идеологически правильным" весь внешний API контрола заворачивать при помощи SendMessage()/add message handler, сваливая всю работу по синхронизаии на нее? Почему в таком случае, в некоторых WTL котролах наружу торчит незавернутый API, и как предполагается решать вопрос с синхронизацией там?
Нужно использовать из всех рабочих (не главного) потоков PostMessage. В отличии от SendMessage оно просто положит сообщение в очередь и оттуда заберётся уже главным потоком автоматически.
Re: UI vs многопоточность
От: bobik123  
Дата: 24.06.09 21:16
Оценка:
Здравствуйте, mjau, Вы писали:

SendMessage опасно тем, что дэдлок можно схватить, если ожидать потока в котором идут операции с контролом.. Можно postMessage использовать.
А так — да, синхронизация так и есть — все что надо выполняется основным потоком, который мессаги обрабатывает. Виндузовые контролы тоже также работают..
Re[2]: UI vs многопоточность
От: Аноним  
Дата: 11.07.09 11:45
Оценка:
> ибо карточка графическая — 1 шт., клавиатура — 1 шт. и мышка тоже — 1 шт.

Обычно, но не всегда.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.