You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the originating work on Real Time for the Masses, tasks could also be run synchronously, i.e., one could call into other tasks as a function call, this allowed to re-factor code along the following lines (not actual syntax)
task a () // no resources used
c (some_args) // synchronous invocation of task_c
task b () // no resources used
c (some_args) // sync call to task_c
task c (some_parameters) // task that uses X
X.lock(
...
)
The static analysis could figure out that X was (synchronously) accessed by tasks a and b. The resource usage was local to c, so you did not need to declare it as a resource of both a and b.
Also as full program analysis was done you did not need to declare the use of resources, it was derived in the analysis.
In RTIC we don't aim for full program analysis (re-parsing all Rust is out of the scope here), so deriving resource usage and call structure is not possible. Nevertheless we could declare sync = [c] in the task attribute and have cx.sync.c(some_arg), to achieve this type of re-factorisation. Not sure if its a common enough pattern to make it worth implementing.
The text was updated successfully, but these errors were encountered:
Synchronous tasks
In the originating work on Real Time for the Masses, tasks could also be run synchronously, i.e., one could call into other tasks as a function call, this allowed to re-factor code along the following lines (not actual syntax)
The static analysis could figure out that
X
was (synchronously) accessed by tasksa
andb
. The resource usage was local toc
, so you did not need to declare it as a resource of botha
andb
.Also as full program analysis was done you did not need to declare the use of resources, it was derived in the analysis.
In RTIC we don't aim for full program analysis (re-parsing all Rust is out of the scope here), so deriving resource usage and call structure is not possible. Nevertheless we could declare
sync = [c]
in the task attribute and havecx.sync.c(some_arg)
, to achieve this type of re-factorisation. Not sure if its a common enough pattern to make it worth implementing.The text was updated successfully, but these errors were encountered: