Doubt in scheduler SMP function _Scheduler_SMP_Schedule_highest_ready

[Richi Dubey]

Thank you for the clarification.

On Wed, Aug 5, 2020 at 1:00 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 04/08/2020 17:57, Gedare Bloom wrote:
> > On Tue, Aug 4, 2020 at 8:14 AM Richi Dubey<richidubey at gmail.com>  wrote:
> >> Hi,
> >>
> >> I have a quick doubt about the logic in the else part of the
> _Scheduler_SMP_Schedule_highest_ready function.
> >>
> > I'll give my understanding. Only Sebastian really understands this
> stuff;)
> >
> >> We get the action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK if the node
> returned by get_highest_ready is already SCHEDULED and has a pinning level
> of 1 (or <=1). This means that the highest ready eligible node is already
> scheduled and pinned to a processor.
> >>
> > This means that the highest ready node cannot be scheduled right now,
> > for some reason. It is the thread that is already scheduled, or the
> > node is busy helping.
> >
> >> Why do we then change its state to BLOCKED and remove it from the chain
> of ready nodes?
> >>
> > If the thread that owns the node can't be scheduled right now (e.g.,
> > it is already scheduled on a different node), then the node should be
> > blocked so we can maybe pick a different node to schedule.
>
> Yes. I tried to improve the documentation a bit:
>
> https://lists.rtems.org/pipermail/devel/2020-August/061144.html
>
> What can be a bit confusing is that we have a scheduled state for
> threads and for scheduler nodes:
>
> /**
>   * @brief The thread state with respect to the scheduler.
>   */
> typedef enum {
>    /**
>     * @brief This thread is blocked with respect to the scheduler.
>     *
>     * This thread uses no scheduler nodes.
>     */
>    THREAD_SCHEDULER_BLOCKED,
>
>    /**
>     * @brief This thread is scheduled with respect to the scheduler.
>     *
>     * This thread executes using one of its scheduler nodes.  This could
> be its
>     * own scheduler node or in case it owns resources taking part in the
>     * scheduler helping protocol a scheduler node of another thread.
>     */
>    THREAD_SCHEDULER_SCHEDULED,
>
>    /**
>     * @brief This thread is ready with respect to the scheduler.
>     *
>     * None of the scheduler nodes of this thread is scheduled.
>     */
>    THREAD_SCHEDULER_READY
> } Thread_Scheduler_state;
>
>
> /**
>   * @brief SMP scheduler node states.
>   */
> typedef enum {
>    /**
>     * @brief This scheduler node is blocked.
>     *
>     * A scheduler node is blocked if the corresponding thread is not ready.
>     */
>    SCHEDULER_SMP_NODE_BLOCKED,
>
>    /**
>     * @brief The scheduler node is scheduled.
>     *
>     * A scheduler node is scheduled if the corresponding thread is ready
> and the
>     * scheduler allocated a processor for it.  A scheduled node is
> assigned to
>     * exactly one processor.  The count of scheduled nodes in this
> scheduler
>     * instance equals the processor count owned by the scheduler instance.
>     */
>    SCHEDULER_SMP_NODE_SCHEDULED,
>
>    /**
>     * @brief This scheduler node is ready.
>     *
>     * A scheduler node is ready if the corresponding thread is ready and
> the
>     * scheduler did not allocate a processor for it.
>     */
>    SCHEDULER_SMP_NODE_READY
> } Scheduler_SMP_Node_state;
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200805/a4cf92fb/attachment.html>