On Mon, Apr 9, 2018 at 11:54 AM, Matthew J Fletcher <ami...@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
