On Tuesday 07 November 2006 15:02, Michael Schnell wrote: > > I always thought a timer is more comparable to an interrupt or > > signal than a polling loop. > > That is a very common misconception.
Indeed. Even a paper in "Embedded Computing Design" about Ada 2005 follows that "very common" misconception: -- quote -- 8< -- Timing events allow for a handler to be executed at a future point in time in an efficient way, as it is a standalone timer that is executed directly in the context of the interrupt handler (it does not need a server task). The use of timing events may reduce the number of tasks in a program and the overhead of context switching. It provides an effective solution for programming short time-triggered procedures and implementing some specific scheduling algorithms, such as those used for imprecise computation. Imprecise computation increases the utilization and effectiveness of real-time applications by means of structuring tasks into two phases (one mandatory and one optional). Scheduling algorithms that try to maximize the likelihood that optional parts are completed typically require changing asynchronously the priority of a task, which can be implemented elegantly and efficiently with timing events. -- /quote -- 8< -- But of course, the Delphi "concept" is right. > A TTimer event is not an > interrupt in that it does not interrupt any code in the Application. > such an "automatic event" is always done in the main thread and only > started when (1) the application is idle, (2) the application comes > back from some other event, or (3) Application.ProcessMessages is > called. Only another thread can be interrupted ("preempted") by such > an event. Those are details of _one_ particular implementation. > The big advantage is that you do not need to protect any resources > from multi-threaded access if you do not explicitly create a thread > by means of TThread. And the big disadvantage seems to be a overly complicated programming model. Guess, what I'd prefer. Vinzent. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel