Timer Server and Blocking Calls

[Joel Sherrill]

Till Straumann wrote:
> RTM:
>
>   
>> 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.
>>
>>     
> VVVVVVVVVVVVVVVVVVVVVVVVV
>   
>> 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 
> server.
>
> 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:
>   
>> Hi,
>>
>> 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 @@
>>  #endif
>>        break;
>>      case OBJECTS_LOCAL:
>> -      _Thread_Unblock( the_thread );
>> +      _Thread_Clear_state( the_thread, STATES_DELAYING );
>>        _Thread_Unnest_dispatch();
>>        break;
>>    }
>>
>> 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.

--joel
>> Have a nice day!
>>
>>   
>>     
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>   


-- 
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