Timers in a task context

[Matthew J Fletcher]

It looks like a difference in operation to say, for example ThreadX, who's
tx_thread_identify() function is documented similarly "If this service is
called from an ISR the return value represents the thread running prior to
the executing interrupt handler", however in operation in ThreadX there is
no non-service, or raw timer interrupt handler, so it always returns the
previous 'user' threads task.

On 10 April 2018 at 09:34, Matthew J Fletcher <amimjf at gmail.com> wrote:

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


-- 

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