🚀 go-pugleaf

"Mike Collins" <mikec@kr8.co.uk> wrote in message
news:4022d173$1@newsgroups.borland.com...

> What is the situation if I enter a Critical Section within
> the OnTimer event of TTimer?

Are there other threads involved also using the same critical section?  If
not, then it has no effect at all.

> As it stands, this all happens under the OnTimer event.
> There is also the main thread of the application
<snip>

If you are using TTimer on a form, then OnTimer is executed in the context
of the main thread.  TTimer is not a multi-threaded timer.  It posts
WM_TIMER messages to the owning thread's message queue.

> 1) The TTimer thread
<snip>

Are you saying that you are actually using a separate worker thread that is
using TTimer internally?  If so, then why are you using TTimer at all?  Why
just just loop the thread with a Sleep() after each iteration?  Even better
would be if the hardware sends out any kind of notification when actual data
is available, then you dn't have to poll at all.

> 2) The TTimer thread could be tired up decoding and thus
> fire a second time or third etc.

Disable the timer when you first enter the handler, and then reenable the
timer when you are finished.

> However I don't really understand what will happen with
> the timer if the event fires a second or third time.

The timer is blocked while its OnTimer event code is running.  If the main
thread has the critical section locked, and you really are using the TTimer
in a separate worker thread (which you shouldn't really need to do), then
the timer is blocked until the main thread releases the critical section.
Which is why you should not keep the critical section locked for any great
length of time.  If all you are doing is fill a structure and read the
structure back, then keep the critical section use to a minimum, locking at
the last possible moment and then releasing it as soon as possible.


Gambit