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
This is not sufficient especially if the parameters are updated dynamically after thread initialization and it first starts running.
For example, updating the priority of a thread after it starts running will not impact on the scheduling in the system until a next timer tick and the current thread continues its execution with the current priorities.
This just means, after thread initialization, if parameters are changed, instead of sl_cs_exit() we'd need to call sl_cs_exit_schedule() so the policy and thread param changes take effect immediately.
One proposal: I think it might be difficult to decide the phases of thread (initialization --> running --> etc, especially if we have multiple parameters to initialize or update).. So I think it would be good to have 2 separate API, one for initialization of thread parameters that doesn't call reschedule, something like sl_thd_param_init, likely mainly used by schedulers on thread creation, and the other sl_thd_param_set that is used after initialization, that always calls reschedule upon updating a thread parameter.
The text was updated successfully, but these errors were encountered:
In the current code base, sl_thd_param_set() doesn't take the CS to update parameters.
We can fix that to just do (see here: b173b2a#diff-96720fe9dba7901d69a833a3c3bee4ab) :
This is not sufficient especially if the parameters are updated dynamically after thread initialization and it first starts running.
For example, updating the priority of a thread after it starts running will not impact on the scheduling in the system until a next timer tick and the current thread continues its execution with the current priorities.
This just means, after thread initialization, if parameters are changed, instead of
sl_cs_exit()
we'd need to callsl_cs_exit_schedule()
so the policy and thread param changes take effect immediately.One proposal: I think it might be difficult to decide the phases of thread (initialization --> running --> etc, especially if we have multiple parameters to initialize or update).. So I think it would be good to have 2 separate API, one for initialization of thread parameters that doesn't call reschedule, something like
sl_thd_param_init
, likely mainly used by schedulers on thread creation, and the othersl_thd_param_set
that is used after initialization, that always calls reschedule upon updating a thread parameter.The text was updated successfully, but these errors were encountered: