about send in rtems_timer_service_routine

[Joel Sherrill]

Daron Chabot wrote:
> Joel Sherrill wrote:
>   
>> Daron Chabot wrote:
>>     
>>> Not having checked send(2) for blocking behavior, this is just a guess:
>>>
>>> The function, rtems_timer_service_routine( ), is called from an
>>> interrupt context. Code called from an interrupt context *cannot*
>>> perform operations that may block waiting for resources (i.e. send(2)).
>>>
>>> You could use an rtems_timer_server instead: this server runs in a
>>> thread context which has no restrictions on the methods invoked from it.
>>>
>>> (see http://www.rtems.com/onlinedocs/releases/rtemsdocs-4.8.0/share/
>>> rtems/html/c_user/c_user00116.html)
>>>
>>>
>>>       
>> I wouldn't say no restrictions.  While in the timer server,
>> dispatching is disabled so blocking is definitely not possible.
>> So a blocking send() wouldn't block, it would continue executing
>> like it didn't block causing havoc.
>>
>> There is another oddity.  By default, the task runs at priority 0
>> which is not possible to set from user applications.  So changing
>> the priority temporarily is impossible -- it can't be restored.
>>
>> See cpukit/rtems/src/timerserver.c.
>>
>>    _Thread_Disable_dispatch();
>>      _Timer_Server_process_ticks_chain();
>>      _Timer_Server_process_seconds_chain();
>>
>> Does it seem like the documentation is overstating how safe
>> this is?
>>     
> No... the problems lie solely with this reader ;-)
>
> The documentation is fine (might be made a little more explicit, though).
> From
> http://www.rtems.com/onlinedocs/releases/rtemsdocs-4.8.0/share/rtems/html/c_user/c_user00122.html:
>     "...However, since the Timer Server task is non-preemptible, only
> directives allowed from an ISR can be called in the timer service routine."
>
>   
>> If so, then we need to either change the documentation
>> or change the critical section management here.
>>     
>
> However, it does seem as though the "priority=0,
> Thread_Disable_dispatch()", makes a Timer-Server nearly as restricted as
> an ISR-context...
>   
Not quite.. you are still really in a thread and can have a
floating point context. 

If someone wants to investigate not disabling dispatch there,
I am open to removing that restriction.  That was done to
keep the calls that process the ticks chain in a state that
was as similar as possible to an ISR. 

It might be possible to safely remove that.  But I wouldn't
personally commit to that without analysis. :-D

--joel
> -- dc
>
>   
>>> -- dc
>>>
>>> On 20-Apr-08, at 2:16 AM, Ray wrote:
>>>
>>>       
>>>> Dear  powerain ,
>>>> Maybe you should check this website first
>>>> http://linuxmafia.com/faq/Essays/smart-questions.html
>>>> here is a mandarin version
>>>> http://www.linuxforum.net/doc/smartq-grand.html
>>>>
>>>> BTW, it seems to me that rtems_timer_service_routine=void if I read
>>>> code correct
>>>>
>>>> Thanks & Best Regards!
>>>>
>>>> Ray, rayx.cn at gmail.com
>>>> 2008-04-20
>>>>
>>>>
>>>> =========================
>>>> ----- Receiving the following content -----
>>>> =========================
>>>> From:  powerain
>>>> Receiver:  rtems-users
>>>> Time: 2008-04-20, 09:25:20
>>>> Subject: about send in rtems_timer_service_routine
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>> hi everyone,
>>>>> i send a package in a rtems_timer_service_routine using send
>>>>> function by a socket.
>>>>> but is does not work.
>>>>> who tell me why.
>>>>> thanks very much.
>>>>>
>>>>> 2008-04-20
>>>>>
>>>>>
>>>>> _____________________ next part ______________________
>>>>>
>>>>> _______________________________________________
>>>>> rtems-users mailing list
>>>>> rtems-users at rtems.com
>>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.com
>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>
>>>>         
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.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