I've faced problems similar to yours in the past, and I've successfully
used a simple and quite effective scheme:
1) a list of timer events, ordered by expiration time. Each entry holds
the absolute time, and the action to take (the semaphore to signal,
where a thread is waiting, in my case). The queue is built as a double
linked list, for ease of insertion/deletion.
2) whenever a new timer event must be scheduled, it's inserted in the
appropriate place of the list. if it happens to go to the head of the
list, the timer must be reprogrammed, otherwise it's left untouched.
3) When the timer expires, the head item is removed from the list, and
the action is activated. Optionally, if timer for next event is lower
than a given threshold, also next event can be activated too, and
removed from the list.
The timer is reprogrammed from the next item in the list (which has
become the head of the list).
If the list has become empty, the timer is not reactivated.
Pros: you have only one timer to deal with, no overhead for useless
timer events, minimal overhead on timer events.
Cons: you have some overhead when programming a timer event, because the
list must be scanned to insert the event in the appropriate place.
Just my 5 c.
Giuliano
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
