I’m thinking about implementing an erlang-like actor framework on top of RTOS. This would require me to create and destroy tasks very fast, as tasks (“processes”) in erlang are the main tool to get things done.
Now I was wondering whether RTOS task API is efficient enough for this. Of course every task is created statically, so I’m using xTaskCreateStatic() for that. Also, I’m using static queues which are create along with the task to send messages to the task. The main issue is I want to be able to spawn tasks inside other tasks stacks which would require very little execution overhead. Is this feasible with FreeRTOS?
@aggarg Yes exactly. I know that it is possible, but I don’t know if it’s a good idea when tasks are created / destroyed every millisecond? Will the overhead be too drastic?
My first impression is that the erlang ‘task’ isn’t actually the same things as a FreeRTOS task. If you can actually create them statically, then you can probably actually just create all of them initially, and rather than destroying the task when it is done, it goes around and waits for someone to ‘create’ it again and do its actions again.
@richard-damon: Indeed they’re not quite the same, but I hope they allow they’re sufficient enough to implement the principle.
Also you’re right that when I instantiate them statically I might as well run them right away until they hit a queue-wait. They respond to a queue anyway so other tasks can “subscribe” to a queue and peek into it to get notified when a task starts to run.
This is now a bit off topic but do you know by any chance if queue receives are always resolved after queue peeks? Because in the above case I would require all peeking tasks to get notified before the new task receives the item on the queue…
To my knowledge when data is put into a queue, the tasks waiting on the queue are processed in order of priority, and if a task reads the data from the queue, then further peeks will fail.
If you want to send a notification to multiple tasks at once, use an event-group, then all the tasks that are waiting will get woken and notified the event happened. The doesn’t help if you actually need to send a value (unless you make the value global and the event is that it was updated, this just doesn’t give a ‘queue’ for values).