Timers in a task context

[Matthew J Fletcher]

Hi,

I think I've managed to narrow it down,. rtems_task_self() is documented as
"If called from an interrupt service routine, this directive will return
the Id of the interrupted task.",.. however if you run a timer server and
your timer is initiated using rtems_timer_server_fire_after(), then
rtems_task_self() will always return 'TIME'.

It does not give the "user" task executing before the 'TIME' task,..
as rtems_timer_fire_after() presumably would.


On 9 April 2018 at 18:59, Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Mon, Apr 9, 2018 at 11:54 AM, Matthew J Fletcher <amimjf at gmail.com>
> wrote:
>
>> Hi,
>>
>> Some other operating systems allow a timer be created that will fire the
>> associated routine in that tasks context. In rtems timers are either in the
>> interrupt or the timer task, either way, not in the context of the task
>> that created the timer.
>>
>>
> FWIW I'm not familiar with an OS that does this.  Happy to see any manuals
> online.
>
>
>> This has caused me some head scratching,. the existing task does
>> something like this...
>>
>> do_bunch_of_stuff()
>> {
>>   forever {
>>   rtems_message_queue_receive( rtems_task_self () -> rtems_id ,
>> wait_forever_no_timeout )
>>   do_something_with_messages_received();
>>   }
>> }
>>
>
> I am not 100% sure what you are trying to accomplish but message queues
> are independent
> objects that tasks/threads block on. You don't pass in the thread id.
> Message queues have
> their own id returned by the rtems_message_queue_create() call.
>
>
>>
>> while another task does,..
>>
>> rtems_timer_create(5_seconds,  do_bunch_of_stuff() );
>> rtems_message_queue_send( do_bunch_task -> rtems_id, blob1 );
>> rtems_message_queue_send( do_bunch_task -> rtems_id, blob2 );
>> rtems_message_queue_send( do_bunch_task -> rtems_id, blob3 );
>> // etc
>>
>> of course when do_bunch_of_stuff() gets invoked by the timer,
>> rtems_task_self() is not going to magically know the task id to return.
>>
>>
>> Whats the best way to deal with this ?, any method i use (events /
>> semaphores, etc) is not going to work because there is already an existing
>> "wait_forever" blocking action,.. i presume i would have to change that to
>> non-blocking then sample the queue every N ?
>>
>>
>> --
>>
>> regards
>> ---
>> Matthew J Fletcher
>>
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>
>


-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180410/734c1a32/attachment-0002.html>