Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TThread + TTimer


Страницы:   1 2

vecna ©   (2005-08-30 16:47:00) 

Че-та мне снова пора в отпуск...
Можно ли успользовать в потоках TTimer? С одной стороны он реализуется APIфункциями, с другой он наследник TComponent и это вызывает сомнения.


Digitman   (2005-08-31 14:19:00) [1]


> Игорь Шевченко ©   (31.08.05 13:48) [31]


ну ладно, что там бестолку рассуждать ...

"вот предет барин - барин нас рассудит")


Игорь Шевченко   (2005-08-31 13:48:00) [2]

Digitman ©   (31.08.05 12:38) [27]


> Об окнах и речи не идет ...


Согласен, об окнах речь не идет. Но о цикле выборки сообщений, в любом случае, речь идет. Которая выборка сообщений тоже обращается к ядру.


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


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


Leonid Troyanovsky   (2005-08-31 13:05:00) [3]


> Суслик ©   (31.08.05 12:51) [29]

> тогда не "свой free", а "свой destroy". Так?


Конечно.
Хорошо, что хоть деструкторы виртуальны :)

--
Regards, LVT.


Суслик   (2005-08-31 12:51:00) [4]


>  [28] Leonid Troyanovsky ©   (31.08.05 12:48)

тогда не "свой free", а "свой destroy". Так?
Тогда понял.


Leonid Troyanovsky   (2005-08-31 12:48:00) [5]


> Суслик ©   (31.08.05 11:36) [23]

> > Ну, и, наверное, свой
> > Free, т.к. Terminate - статический.

> А вот этого не понимаю? Это про что?


В реализации Destroy можно увидеть Terminate, однако,
т.к. Terminate не виртуальный, то вызван будет он,
а не новая его реализация.

Т.е., если кто-то привык к тому, что Free остановит поток,
то должен озаботится и своим деструктором,
который вызовет нужный Terminate.

--
Regards, LVT.


Digitman   (2005-08-31 12:38:00) [6]


> Игорь Шевченко ©   (31.08.05 12:08) [26]


> Не совсем шило на мыло. Тебе не надо делать окон, обрабатывать
> у них WM_TIMER и т.п


Об окнах и речи не идет ...
А ожидание WM_TIMER при SetTimer() точно так же как и ожидание колбэка при SetWaitableTimer() требует kernel time, так что никаких явных преимуществ задействования того или иного таймера в таком абстрактном изложении автором задачи я не вижу


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


В том-то и дело, что эта концепция вроде бы противоречит авторскому видению решения ...
Ему ведь нужно что ? Ему, как пока видно из его постов, нужно следующее : запустить какой-то там таймер (который будет отсчитывать некие предельно малые интервалы времени) и спокойно продолжать делать в трэде свои "дела", не задумываясь ни о каких "режимах ядра", "тревожных состояниях", "ожиданиях" и прочей непонятной и потому якобы несущественной лабуде ..
Мол, когда таймер тикнет, то выполнение некоего основного алгоритма трэда само по себе (!) прервется и при этом будет вызвана некая п/программа, где первым делом будет осуществляться проверка флага Terminated на предмет не закруглиться ли немедленно этому трэду "по хозяйству"..


Игорь Шевченко   (2005-08-31 12:08:00) [7]

Digitman ©   (31.08.05 11:58) [25]

Не совсем шило на мыло. Тебе не надо делать окон, обрабатывать у них WM_TIMER и т.п.

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


Digitman   (2005-08-31 11:58:00) [8]


> Игорь Шевченко ©   (31.08.05 11:51) [24]


Все бы было расчудесно, Игорь, если бы не ма-а-аленькая "загвозка":

If you call SetWaitableTimer and the thread is not in an alertable state, the completion routine is canceled

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

шило на мыло, ч.н.)


Игорь Шевченко   (2005-08-31 11:51:00) [9]

Digitman ©   (31.08.05 11:31) [22]


> для обнаружения и обработки "тика" таймера трэд как правило
> должен переключиться в kernel time


Вах! Зачем переключаться ? в SetWaitableTimer указываешь, какую процедуру надо вызывать при достижении нужного интервала, например.

hint: вызовы для получения и обработки сообщений тоже в режиме ядра выполняются, так что профит несущественный :)


Суслик   (2005-08-31 11:36:00) [10]


>  [12] Leonid Troyanovsky ©   (31.08.05 09:13)
> Про true уже говорили, т.е., лучше while GetMessage do.


ну это типа "быстрый" пример, не претендующих на законченность.


> Кроме того, для такого потока лучше сделать свой Terminate,
> который пошлет потоку WM_QUIT.


Это я понимаю зачем - иначе не прервется ожидание getmessage и все "зависнет".


> Ну, и, наверное, свой
> Free, т.к. Terminate - статический.


А вот этого не понимаю? Это про что?

-----------
За поправки про окно спасибо, интересно было почитать.


Digitman   (2005-08-31 11:31:00) [11]


> Игорь Шевченко ©   (31.08.05 11:09) [20]


пока трэд работает в user time, толку от таймера, сам понимаешь, нет никакого - для обнаружения и обработки "тика" таймера трэд как правило должен переключиться в kernel time .. для немедленной реакции на "тик" это переключение требуется выполнять насколько это возможно чаще, при этом "полезная деятельность" трэда сводится к нулю, ибо "окон" в user time становится все меньше и меньше ... и нужен ли в конечном итоге такой трэд, который только и делает, что чуть ли не без конца (от "рождения" до "смерти") беспокоится только о том, не сработал ли таймер - это нужно осознать прежде всего автору сабжа ..


Digitman   (2005-08-31 11:18:00) [12]


> Alexander Panov


"ключевой" момент всей этой затеи (цитирую автора):


> vecna ©   (30.08.05 17:19) [7]
> Нужно уметь парктически сразуопределять, что Terminated
> = true.


Автор, очевидно, наивно предполагает, что таймер - это такая волшебная штука, которая "тикнув" в нужный момент времени немедленно и безусловно "прервет" исполнение трэда ( чем быон, трэд, ни был в этот момент занят) и при этом можно будет проконтролировать состояния флага Terminated, дабы тут же должным образом отреагировать на него.

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


Игорь Шевченко   (2005-08-31 11:09:00) [13]

Я бы WaitableTimer использовал или TimerQueue, ни с какими окнами не связано.

По поводу того, зачем нужен таймер в потоке - периодически что-то опрашивать, например, не нагружая основной поток. Аська, например, опрашивает что-то периодически, не мешая набирать сообщение...


Alexander Panov   (2005-08-31 11:00:00) [14]

Reindeer Moss Eater ©   (31.08.05 10:55) [17]
Поэтому таймер там - не нужен вовсе.


ну почему же - SetTimer- нормальный вариант.


Alexander Panov   (2005-08-31 10:57:00) [15]

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


Reindeer Moss Eater   (2005-08-31 10:55:00) [16]

В любомслучае в потоке будет цикл, либо поток будет использовать функцию ожидания (опять же в цикле)
Поэтому таймер там - не нужен вовсе.


Leonid Troyanovsky   (2005-08-31 10:12:00) [17]


> Reindeer Moss Eater ©   (31.08.05 09:48) [15]
> Вопрос бы в том, что будет делать поток, ожидая тика.
> Что бы ждать тика поток должен крутить цикл, в котором конечно
> он может еще и ждать сообщений и обрабатывать их.
> То есть в любом случае необходим цикл.


RTFM: GetMessage.
А лучше почитать Рихтера, про потоки и их очереди.
И про то, что такое спящие потоки.


> Отсюда и вытекает второй вопрос: а таймер-то зачем здесь
> приплетать?


Этот вопрос, видимо, не ко мне.

--
Regards, LVT.


Reindeer Moss Eater   (2005-08-31 09:48:00) [18]

Вопрос бы в том, что будет делать поток, ожидая тика.
Что бы ждать тика поток должен крутить цикл, в котором конечно он может еще и ждать сообщений и обрабатывать их.
То есть в любом случае необходим цикл.
Отсюда и вытекает второй вопрос: а таймер-то зачем здесь приплетать?


Leonid Troyanovsky   (2005-08-31 09:36:00) [19]


> Reindeer Moss Eater ©   (31.08.05 09:22) [13]
> >Ждать сообщений - GetMessage.
> Круто. А без таймера ему конечно ждать скучно будет.


Я ответил, что он будет делать, ожидая сообщения таймера.
Просто ждать. Скучно ему будет или нет, мне пофиг.

--
Regards, LVT.


Reindeer Moss Eater   (2005-08-31 09:22:00) [20]

>Ждать сообщений - GetMessage.
Круто. А без таймера ему конечно ждать скучно будет.


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо