TThread + TTimer

← →
Digitman © (2004-01-15 12:40) [40]

> Dred2k © (15.01.04 12:29) [34]
> > Digitman © (15.01.04 12:22) [28]
>
> Не факт. Может и не получить.

"в любом случае" - здесь имелось ввиду не гарантия доставки сообщения, а то что именно кодовый поток ответственен за выборку сообщений изо всех его интересующих (и ассоциированных с ним и его окнами) очередей

> The function fails if the specified thread does not have
> a message queue. The system creates a thread"s message queue
> when the thread makes its first call to one of the Win32
> USER or GDI functions.

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

поэтому одним из грамотных подходов к реализации корректной логики является следующий :

поток-отправитель :
while not PostThreadMessage() do ..

поток-получатель же должен сразу после старта как можно быстрее вызвать любую из ф-ций, отвечающих за выборку сообщений из очереди (при первом же вызове очередь будет создана), например :

PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE)

← →
snake1977 (2004-01-15 12:44) [41]

>>Digitman ©
объясняю почему не Timer который запускает Thread. Программа посотренна таким образм: есть главный модуль который запускает процедуры из прописанных в его настройках DLL модулях. Каждая из запускаемых процедур отвечает только за свою фунукцию, например одна прослушивает сокет и получая сообщение записывает его в файл, другая просмотривает диск на наличие файлов определнного вида, найдя открывает и обрабатывает выкладывая результат в другой файл. третья просмотривает файлы ответов и отправляет его через сокет :) вот примерно так. Количество таких модулей заранее не известно и период срабатывания каждой из процедур также может быть различен. при всем при этом естесвтенно что модуль овечающий за например прослушивание сокета не как не связан и не джолжен мешать работе модуля обрабатывающего файлы. вот по тому и надо сделать паралельное функционирование различных модулей , которые обрабатывают информацию в различные периоды времени

← →
Dred2k © (2004-01-15 12:52) [42]

> Digitman © (15.01.04 12:40) [40]

> поток ответственен за выборку сообщений

> здесь имелось ввиду
"в любом случае" - оставляет не слишком много вариантов. Теперь понятно.

> поэтому одним из грамотных подходов к реализации корректной
логики является следующий ...

Я бы сказал, что это не "грамотный подход", а однозначно документированные требования.

← →
Nikolay M. © (2004-01-15 12:53) [43]

> snake1977 (15.01.04 12:44) [41]

Не влезая в суть разбирательств, обращаю внимание на [36] и рекомендую еще посмотреть TRxTimerList. Хотя это дело хозяйское.

← →
Verg © (2004-01-15 12:54) [44]

> snake1977 (15.01.04 12:44) [41]

Все понятно, непонятно для чего в этих потоках тебе TTimer, т.е. этот компонент именно?
Для отсчета таймаутов и безо всяких TTimer хватает средств.

← →
Digitman © (2004-01-15 12:55) [45]

> snake1977 (15.01.04 12:44) [41]

кинь на форму один-единственный TTimer, установи нужный период срабатывания

в обработчике OnTimer() создавай один или более объектов-наследников TThread, метод Execute каждого из которых будет заниматься своим делом и никак не будет мешать иным потокам

осн.потоку остается только при каждом тике таймера проверять состояние завершенности тех или иных потоков, чтобы не создавать лишние

← →
Digitman © (2004-01-15 12:57) [46]

> Dred2k © (15.01.04 12:52) [42]
> Я бы сказал, что это не "грамотный подход", а однозначно
> документированные требования.

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

← →
Dred2k © (2004-01-15 13:00) [47]

По-моему, тут проще можно. Передаем в нитку при создании отправное значение GetTickCount (для синхронизации) и расписание срабатываний. Далее поток просто считает тики и сверяет с расписанием, когда нужно - срабатывает.

← →
Verg © (2004-01-15 13:03) [48]

> Digitman © (15.01.04 12:55) [45]
>
> > snake1977 (15.01.04 12:44) [41]
>
>
> кинь на форму один-единственный TTimer, установи нужный
> период срабатывания
>
> в обработчике OnTimer() создавай один или более объектов-наследников
> TThread, метод Execute каждого из которых будет заниматься
> своим делом и никак не будет мешать иным потокам

А что, без таймера никак нельзя запустить несколько кодовых потоков, каждый из которых вызовет нужную свою ф-цию из DLL?

← →
Dred2k © (2004-01-15 13:06) [49]

> Digitman © (15.01.04 12:57) [46]

> непонятно только зачем ты цитировал хэлп - мне это известно
не хуже тебя
Это хорошо. Молодец.

P.S.
А действительно - с какого такого перепоя я вдруг без высочайшего разрешения позволил себе процитировать ВАМ (простиТЕ, большЕЕ буковок нет) хелп.
Непозволительная грубость. Исключительный цинизмъ.

P.P.S.
Все хорошо в меру. В том числе и жажда научить.

← →
Digitman © (2004-01-15 13:08) [50]

> Verg © (15.01.04 13:03) [48]

а я почем знаю ? я именно так понял задачу автора из его слишком общих и не совсем терминологически корректных объяснений

все зависит от

> которые обрабатывают информацию в различные периоды времени

что за периоды, как они связаны с центральной логикой управления потоками - мне не понятно на сей момент из вышеизложенного

← →
Verg © (2004-01-15 13:09) [51]

> Далее поток просто считает тики и сверяет с расписанием,
> когда нужно - срабатывает.

Я че-то не пойму - где в ТЗ (snake1977 (15.01.04 12:44) [41] ) :) упоминание о каких-либо "расписаниях" ?

Там явно написано, что потоки должны быть независимы и выполняться одновремено

← →
Digitman © (2004-01-15 13:09) [52]

> Dred2k © (15.01.04 13:06) [49]

без комментариев

> обрабатывают информацию в различные периоды времени

По-моему, это "переводится", как "Обрабатывают информацию за различное время"
Т.е. одна ф-ция может управится со своей работой за 1 сек, а другой и 5-ти минут может не хватить.

> Verg © (15.01.04 13:16) [53]

нет, мне здесь иное не понятно - то ли планирование запуска должно быть реализовано с учетом некоего центрального расписания (которое вполне могло быть у автора реализовано и в осн.потоке), то ли осн.поток сразу стартует N доп.потоков и за сим успокаивается (потоки же после старта сами реализуют индивидуальные расписания), то ли и сами потоки запускаются по расписанию и затем реализуют внутри себя еще и собственные расписания ...

А почему обязательно Timer? Штука это низкоприоритетная и не слишком точная. Sleep надежен, но тоже неточен.

Хорошее и простое решение получается с WaitableTimer, причем можно вынести его обработку в отдельный поток с тем, чтобы он периодически будил остальные потоки...

> Verg © (15.01.04 13:09) [51]

> snake1977 (15.01.04 12:44) [41]
которые обрабатывают информацию в различные периоды времени

то ли имеется в виду параллельность работы, то ли некие конкретные периоды между выполнением прикладных дейтсвий. Надеюсь, будут пояснения.

если требуется некая универсальность, дабы не плодить кучу классов-наследников TThread, можно реализовать единственного наследника, в теле Execute которого запустить цикл выборки/диспетчеризации сообщений :

while not Terminated and GetMessage(Msg, 0, 0 0) do
if Msg.hWnd = 0 then
Dispatch(Msg.message) //обработка сообщений данному потоку
else
DispatchMessage(Msg); //обработка сообщений окнам, потенциально создаваемым в контексте данного потока

теперь некий поток-координатор (пусть это будет осн.поток) в соответствии с событиями некоего расписания запуска неких п/программ (неважно где находящихся, лишь бы в тек. ВАП их тела были) посылает сообщение первому же найденному потоку, свободному от обработки предыд.сообщений, сообщение с параметрами, указывающими на адрес п/программы, которую следует запустить в контексте найденного потока, и параметрами, которые следует передать этой п/программе при ее вызове

← →
gaa (2004-01-15 17:06) [58]

constructor TWaitableTimer.Create(Name: PAnsiChar = nil);
begin
FTimerHandle:= CreateWaitableTimer(nil,True,Name);
FEnabled:= False;
FDueTime:= WT_MSec;
FResume:= False;
FPeriod:= wtpPeriod;
FTimerContext:= nil;
FName:= Name;
// OpenWaitableTimer($1F0003,False,Name)
end;

TThread + TTimer Найти похожие ветки