Skip to content

sl_thd_param_set() API behavior after initialization #407

@phanikishoreg

Description

@phanikishoreg

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions