Организация межпотокового взаимодействия

← →
fs_more (2006-08-28 22:53) [0]

Ситуация: есть приложение, в котором обработка действий пользователя осуществляется в главном потоке (VCL), а непосредственная работа с массивом данных вынесена в отдельный поток, чтобы дать возможность выполнять некоторые задачи в фоне, незаметно для пользоавтеля. Дополнительный поток получает задания на выполнение через специальнцю очередь команд (реализована в виде массива и 2х указателей/маркеров, показывающих позицию чтения и записи). После выполнения некоторых "заданий" в доп потоке требуется изменение в VCL-компонентах формы. Сейчас выполняю эти изменения напрямую из доп потока (без метода Sybcronize). Работает.
Вопрос. Как лучше реализовать эту задачу? Есть опасения на счет прямого доступа к VCL из потока. Но и есть необходимость вносить изменения/показывать результаты работы. Вторую очередь организовывать не очень хочется. Есть мысли посылать оконные сообщения из доп потока главному окну (главному потоку). Насколько эта идея хороша? Какие другие схемы работы такой программы возможны? Как они будут вести себя в вопросах надежности, скорости/время реакции? Важен еще и вопрос доступа к данным только из доп потока, чтобы данные не могли быть повреждены при совместном доступе.
Заранее спасибо за любые мысли по поводу.

← →
jack128 © (2006-08-28 23:43) [1]

fs_more (28.08.06 22:53)
После выполнения некоторых "заданий" в доп потоке требуется изменение в VCL-компонентах формы. Сейчас выполняю эти изменения напрямую из доп потока (без метода Sybcronize). Работает.
это только на твоем компе. У пользователей работать перестанет.

fs_more (28.08.06 22:53)
Есть мысли посылать оконные сообщения из доп потока главному окну (главному потоку). Насколько эта идея хороша?
Хорошая. Собственно Synchronize так до шестой версии и работала, через SendMessage посылала сообщения окну в главном потоке. Если тебе не нужно в доп потоке ждать пока отработает код в основном потоке - то лудше использовать PostMessage.

fs_more (28.08.06 22:53)
полнительный поток получает задания на выполнение через специальнцю очередь команд (реализована в виде массива и 2х указателей/маркеров, показывающих позицию чтения и записи).
10 раз перепроверь всю эту схему, а потом выкинь её на хрен ;-) Организуй в доп. потоке свою очередь выборки сообщений, и через PostThreadMessage передовай данные из основного в доп поток для обработки.

← →
Ketmar © (2006-08-28 23:54) [2]

> [0] fs_more (28.08.06 22:53)
> Сейчас выполняю эти изменения напрямую из доп потока (без
> метода Sybcronize).
экстремал. %-) не надо так делать -- не обучена VCL многопоточности. обязательно где-нибудь и когда-нибудь свалится. причём в самый неподходящий момент.

> Дополнительный поток получает задания на выполнение через
> специальнцю очередь команд
для этого есть какие-то особые причины? PostThreadMessage(). не забыть в потоке вызвать какую-нибудь user32-функцию, чтобы создалась очередь сообщений. окно иметь не обязательно.

> Есть опасения на счет прямого доступа к VCL из потока
и вполне обоснованные.

> Есть мысли посылать оконные сообщения из доп потока главному
> окну (главному потоку).
умная и своевременная мысль. дёшево и удобно. PostMessage() или SendNotifyMessage(). в данном случае я бы предпочёл вторую за более "говорящее" название. не забывать о том, что не надо передавать AnsiString"и.

> Важен еще и вопрос доступа к данным только из доп потока,
> чтобы данные не могли быть повреждены при совместном доступе.
критические секции или TMultiReadExclusiveWriteSynchronizer.

← →
Суслик © (2006-08-28 23:56) [3]

> Есть опасения на счет прямого доступа к VCL из потока.

Опасения вроде верные - vcl принципиально однопоточная. работать может (сам видел), но это опасно

>Но
> и есть необходимость вносить изменения/показывать результаты
> работы.

Посылай (postXXX) сообщения окну, которое дожно отображать.

> Есть мысли посылать оконные сообщения из доп потока главному
> окну (главному потоку). Насколько эта идея хороша?

Рабочая идея. Правда, зависит от конкретитика, коей не очень много в вопросе.

>Какие
> другие схемы работы такой программы возможны?

Ну... можно чисто winapi окно в еще одном потоке сделать и его юзать многопоточно. Но тут ты сам хозяин - должен сделать так чтобы не глючило.1

> Как они будут
> вести себя в вопросах надежности, скорости/время реакции?

Про время реакции и вообще про рекцию в вопросе не много слов.

> Важен еще и вопрос доступа к данным только из доп потока,
> чтобы данные не могли быть повреждены при совместном доступе.

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

← →
TUser © (2006-08-29 06:29) [4]

Мастера, а чем плохо

> Дополнительный поток получает задания на выполнение через
> специальнцю очередь команд (реализована в виде массива и
> 2х указателей/маркеров, показывающих позицию чтения и записи).
>

?

Учитывая, что потоков (судя по топику) только два. Если грамотно реализовать - будет работать. В грамотной реализации не вижу большой сложности и подводных камней - прошу ткнуть меня носом.

← →
evvcom © (2006-08-29 08:36) [5]

> [4] TUser © (29.08.06 06:29)

А смысл изобретать велосипед, если в WinAPI уже катается такой?

← →
Ketmar © (2006-08-29 09:52) [6]

> [4] TUser © (29.08.06 06:29)
так и всё остальное, что API даёт, можно, в принципе, руками сделать. а зачем?

← →
DiamondShark © (2006-08-29 13:49) [7]

> а зачем?

Через PostThreadMessage можно запостить два длинных слова. Что делать, если элемент задания -- сложная структура?

← →
Ketmar © (2006-08-29 15:02) [8]

> [7] DiamondShark © (29.08.06 13:49)
статическая -- давать адрес. динамическая -- тоже. или сделать окно, и WM_COPYDATA. один фиг в "рукописном" варианте будет то же самое.

← →
ANB © (2006-08-29 15:11) [9]

Воткну свое имхо :
пересмотреть задачу и подумать - а нельзя ли без потоков то обойтись ?
В 90%, когда их используют (со всеми сопутстсвующим граблями), выясняется, что обход граблей вполне можно было не писать, т.к. задача прекрасно работает в одном потоке. Кстати, еще таймеры есть.

← →
Пусик © (2006-08-29 23:22) [10]

> Ketmar © (29.08.06 15:02) [8]
> > [7] DiamondShark © (29.08.06 13:49)
> статическая -- давать адрес. динамическая -- тоже. или сделать
> окно, и WM_COPYDATA. один фиг в "рукописном" варианте будет
> то же самое.

Не то же самое.

Для обработки динамчески поступающих данных и обмена с другими потоками вполне достаточно реализации TThread, поэтому совсем необязательно изобретать дополнительные средства для обмена.
К тому же реализация предельно проста.

← →
fs_more (2006-08-30 01:34) [11]

Ketmar
> PostThreadMessage(). не забыть в потоке вызвать какую-нибудь
> user32-функцию, чтобы создалась очередь сообщений. окно
> иметь не обязательно.
>

вот тут бы поподробнее. если сообщение принимает форма - понятно, а как его принимать в потоке? как это должно выглядеть? при чем тут вызов user32-функции?

А что такое "user32-функция" ?

> [11] fs_more (30.08.06 01:34)
справку не пробовали читать? в частности -- по PostThreadMessage()? вы-таки будете смеятся, но при обращении к функциям из user32 создаётся очередь сообщений потока. куда можно посылать, откуда можно выбирать.

> [12] Fay © (30.08.06 02:31)
это мой не слишком удачный речевой оборот. %-)

> а как его принимать в потоке?

Так и принимать: GetMessage или PeekMessage

> как это должно выглядеть?

Как обычный цикл выборки сообщений. Только, разумеется, без диспетчеризации по окнам.

← →
fs_more (2006-09-30 22:21) [16]

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

Всем участвовавшим в обсуждении спасибо.

Организация межпотокового взаимодействия Найти похожие ветки