Timer Server and Blocking Calls

Thomas Doerfler Thomas.Doerfler at embedded-brains.de
Thu Nov 19 18:00:12 UTC 2009


Hi,

just some additions from my side:
Today I have reviewed the code together with Sebastian. I am not deep
into every detail of the previous timer server implementation but I have
seen that it had various bugs and flaws. Sebastian has mentioned them in
his mail. The most sever from my point of vierw is that the current
implementation could corrupt the task ready chain in certain conditions.

I have discussed some of the new implementation details with Sebastian
and after discussions of how it might be improved we came back to the
really implemented version because any simpler, alternate approaches did
not fulfill all requirements. One additonal goody of the new
implementation is, that it is a step towards getting multiple time
servers for different purposes.

Nevertheless I would ask anybody interested to look into the code and
see what might be wrong before it gets committed.

wkr,
Thomas.


Sebastian Huber schrieb:
> Hi,
> 
> I reworked the timer server implementation.
> 
> The previous timer server implementation had some drawbacks.  Firstly it did
> not work because the thread delay ended function (_Thread_Delay_ended) removes
> all blocking states which could result in an unrelated unblock with fatal
> consequences (destroyed ready chains and arbitrary code execution).  Secondly
> it was the duty of the timer server thread to process insertions of new timers
> and manipulations of running timers.  So a context switch was necessary for
> each timer operation.  This can be a major performance problem in case you use
> a timer for timeout monitoring.
> 
> With the new implementation you are able to block on any resource or time
> within a timer service routine.  No context switches are necessary to
> manipulate timers of the timer server.  The data used by the timer server is
> structured in an timer server control block (_Timer_server_Control).  So it is
> easy to create more instances of timer servers to use different priorities and
> modes for different domains of timer service users (currently no API exists for
> this).
> 
> The classic timer server API did not change through the new implementation.
> 
> It is difficult to get the implementation right since the timer may be
> manipulated from interrupt service routines, threads and routines invoked by
> the timer server itself.  It is not possible to use mutexes because ISRs cannot
> block.  Please have a look at the attached patch.
> 
> CU
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9



More information about the users mailing list