[fpc-devel] TTimers and TThreads. Attn Michael Schnell
Giuliano Colla
giuliano.colla at fastwebnet.it
Fri Jun 27 13:39:50 CEST 2014
Il 27/06/2014 13:10, Michael Schnell ha scritto:
> On 06/27/2014 12:54 PM, Giuliano Colla wrote:
>>
>> 1) a list of timer events, ordered by expiration time.
> Thanks for the pointers.
>
> I in fact do something similar.
>
> My TTimer class has a class variable that is a dynamic array of TTimers.
>
> When the program is going to wait for anything (a timer or a thread
> firing an event) it searches for the next timer to expire and uses the
> difference time as a waiting timeout.
>
> I don't sort the list, as it would need to be re-sorted with any timer
> event. So I always need to do a linear search for the next Timer to
> expire.
>
If you're using relative times and not absolute ones, then you may avoid
the search, without need to resort, using a slightly different scheme,
i.e. entering in a sorted list the times *relatives to the previous one*.
You have event a) to occur 10ms from now, and event b) to occur 100ms
from now: event b) will be entered with a value of 90 (i.e. 100-10). If
you have a third event to occur 50ms from now, it will be entered
between the first and the second, being 50 > 10 and (50-10) < 90, with a
value of 40 (50-10). The time for the following event will be corrected
to 50 (90-40).
The insertion involves the overhead to calculate how much of the time
for the first timer to expire has already passed, and to insert the new
event in the right place, adjusting also the following, but it involves
less overhead than scanning a possibly long list to find the event to
fire. You must always scan the full list, because two event may fire at
the same time. With this scheme an event simultaneous to the previous
one would have a timer value of zero.
If you're in Linux environment, however, the actual libc functions
provide only absolute times, and they're quite efficient. I can't say
about Windows.
Giuliano
More information about the fpc-devel
mailing list