Combine/Distribute: When to chose one over the other Topic is solved
-
- XCore Addict
- Posts: 191
- Joined: Tue Jul 05, 2016 2:19 pm
Combine/Distribute: When to chose one over the other
I have written a simple task that manages a bunch of LEDs. I can declare it as both [[combinable]] or [[distributable]] and am wondering: What criteria might make me chose one over the other? (in general, not just in this case)
View Solution
-
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
Hi DemoniacMilk,
The [[combinable]] or [[distributable]] are quite similar in many ways - they provide a way to ensure that a function does not consume its own logical core but will instead run on a core with other code.
The fundamental difference is that a distributable task must only handle interface calls while a combinable task can also handle resource (timer/port/channel) events.
The distributable task will execute on the logical core which makes the interface calls (with locking to ensure that shared state is protected). An example of this would be the i2c master where performing read/write transactions on the i2c bus can be done by any logical core, but only by one at a time. There is no need for the i2c master to be listening for events on the ports.
The combinable task will execute on the one logical core where it is combined with other tasks. This allows you to reason about whether all the combined tasks will still meet their real-time requirements.
Hope that helps,
Peter
The [[combinable]] or [[distributable]] are quite similar in many ways - they provide a way to ensure that a function does not consume its own logical core but will instead run on a core with other code.
The fundamental difference is that a distributable task must only handle interface calls while a combinable task can also handle resource (timer/port/channel) events.
The distributable task will execute on the logical core which makes the interface calls (with locking to ensure that shared state is protected). An example of this would be the i2c master where performing read/write transactions on the i2c bus can be done by any logical core, but only by one at a time. There is no need for the i2c master to be listening for events on the ports.
The combinable task will execute on the one logical core where it is combined with other tasks. This allows you to reason about whether all the combined tasks will still meet their real-time requirements.
Hope that helps,
Peter
-
- XCore Addict
- Posts: 191
- Joined: Tue Jul 05, 2016 2:19 pm
Thank you for the explanation.
I am wondering what the benefit of using distributable tasks is then. Does it not consume chanends?
I am wondering what the benefit of using distributable tasks is then. Does it not consume chanends?
-
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
Not consuming channel ends is one possible advantage. The other is that the fact that the task is executing in the calling logical core means that it uses less resources. Normally, if a task calls an interface method then that logical core and the one handling the interface call will both have to be involved. The distributable version will all happen locally on the calling logical core.
Clearly there is the limitation that all the clients of a distributable task must be on the same tile.
Peter
Clearly there is the limitation that all the clients of a distributable task must be on the same tile.
Peter
-
- XCore Addict
- Posts: 191
- Joined: Tue Jul 05, 2016 2:19 pm
Alright, thanks again!