Timers in a task context

[Matthew J Fletcher]

Hi

It would be good to know if rtems_task_self() is expected to return the
'TIME' a.k.a rtems_timer_initiate_server() task id, when a timer created
with rtems_timer_server_fire_after() fires.

If it is then i will have to make up some work around, as quite a bit of
code thats coming over from ThreadX depends on, it returning the previous
'user' task, not the previous 'system' task.

Personally it does feel wrong that the behavior of  rtems_task_self()
changes behavior depending if you use the timer server or not.



On 10 April 2018 at 10:19, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 10/04/18 11:11, Matthew J Fletcher wrote:
>
>> 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.
>>
>
> These timer routines executing in the context of a particular thread look
> more like a signal. You could use a timer and then send a signal to a task
> in RTEMS. However, I would not use signals in RTEMS due to their
> implementation (there is a potential infinite recursion).
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>


-- 

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