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) :
sl_cs_enter()
// set the parameter
sl_cs_exit()
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.
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_setthat is used after initialization, that always calls reschedule upon updating a thread parameter.