composite icon indicating copy to clipboard operation
composite copied to clipboard

sl_thd_param_set() API behavior after initialization

Open phanikishoreg opened this issue 4 years ago • 0 comments

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: https://github.com/gwsystems/composite/commit/b173b2a7f0943c08d46cbc6b2888607d6c6d6d1e#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.

phanikishoreg avatar Aug 28 '20 12:08 phanikishoreg