Timer Server and Blocking Calls
joel.sherrill at OARcorp.com
Tue Nov 10 19:06:38 UTC 2009
Till Straumann wrote:
>> The Timer Server task is responsible for executing the timer service
>> routines associated with all task-based timers. This task executes at
>> a priority higher than any RTEMS application task, and is created
>> non-preemptible, and thus can be viewed logically as the lowest
>> priority interrupt.
>> By providing a mechanism where timer service routines execute in task
>> rather than interrupt space, the application is allowed a bit more
>> flexibility in what operations a timer service routine can perform.
>> For example, the Timer Server can be configured to have a floating
>> point context in which case it would be safe to perform floating point
>> operations from a task-based timer. Most of the time, executing
>> floating point instructions from an interrupt service routine is not
>> considered safe.
>> However, since the Timer Server task is non-preemptible, only
>> directives allowed from an ISR can be called in the timer service routine.
>> The Timer Server is designed to remain blocked until a task-based
>> timer fires. This reduces the execution overhead of the Timer Server.
> I'd say it is a programming error for a user callback to block the timer
> That said - it would be a good idea to detect such a situation, alert
> the user
> and panic.
The purpose of adding the timer server was to allow you to
potentially do time consuming and (if you needed to) block.
I would say it isn't good programming but you might not be
able to avoid it since you could be doing something that
requires the C++ or Ada language runtime and it could
lock a mutex and block.
Sebastian... state explained below.
> -- Till
> Sebastian Huber wrote:
>> is it allowed that a function executed within the timer server context blocks
>> while acquiring a resource?
>> If it is allowed then the timer server has a bug. The clock tick readies the
>> timer server via a _Thread_Unblock() which does not take into account that the
>> timer server may block due to something other than a delay. This may fix it:
>> Index: cpukit/score/src/threaddelayended.c
>> RCS file: /usr1/CVS/rtems/cpukit/score/src/threaddelayended.c,v
>> retrieving revision 1.6
>> diff -u -r1.6 threaddelayended.c
>> --- cpukit/score/src/threaddelayended.c 31 Dec 2008 03:36:04 -0000 1.6
>> +++ cpukit/score/src/threaddelayended.c 10 Nov 2009 12:06:49 -0000
>> @@ -59,7 +59,7 @@
>> case OBJECTS_LOCAL:
>> - _Thread_Unblock( the_thread );
>> + _Thread_Clear_state( the_thread, STATES_DELAYING );
>> I do not know how this affects rtems_task_wake_when() and the
>> STATES_WAITING_FOR_TIME state. What is the difference between
>> STATES_WAITING_FOR_TIME and STATES_DELAYING?
/** This macro corresponds to a task waiting until a specific TOD. */
#define STATES_WAITING_FOR_TIME 0x00010
/** This macro corresponds to a task which is waiting for a timeout. */
#define STATES_DELAYING 0x00008
So one is wall time, one is an interval.
My first thought is that it breaks wake_when.
Without giving it much thought, it might be better to define another
state bit for blocking and waking up internal tasks. Or have the
timer server switch to using events.
>> Have a nice day!
> rtems-users mailing list
> rtems-users at rtems.org
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users