[PATCH 30/45] score: Rework _Thread_Change_priority()

[Gedare Bloom]

On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Move the writes to Thread_Control::current_priority and
> Thread_Control::real_priority into _Thread_Change_priority() under the
> protection of the thread lock.  Add a filter function to
> _Thread_Change_priority() to enable specialized variants.
>
> Avoid race conditions during a thread priority restore with the new
> Thread_Control::priority_restore_hint for an important average case
> optimizations used by priority inheritance mutexes.
>
> Update #2273.
> ---
> @@ -653,9 +676,21 @@ struct Thread_Control_struct {
>    Objects_Control          Object;
>    /** This field is the current execution state of this thread. */
>    States_Control           current_state;
> -  /** This field is the current priority state of this thread. */
> +
> +  /**
> +   * @brief This field is the current priority state of this thread.
> +   *
> +   * Writes to this field are only allowed in _Thread_Initialize() or via
> +   * _Thread_Change_priority().
> +   */
>    Priority_Control         current_priority;
> -  /** This field is the base priority of this thread. */
> +
> +  /**
> +   * @brief This field is the base priority of this thread.
> +   *
> +   * Writes to this field are only allowed in _Thread_Initialize() or via
> +   * _Thread_Change_priority().
> +   */
>    Priority_Control         real_priority;
>
>    /**
> @@ -666,6 +701,17 @@ struct Thread_Control_struct {
>     */
>    uint32_t                 priority_generation;
>
> +  /**
> +   * @brief Hints if a priority restore is necessary once the resource count
> +   * changes from one to zero.
> +   *
> +   * This is an optimization to speed up the mutex surrender sequence in case
> +   * no attempt to change the priority was made during the mutex ownership.  On
> +   * SMP configurations atomic fences must synchronize writes to
> +   * Thread_Control::priority_restore_hint and Thread_Control::resource_count.
> +   */
> +  bool                     priority_restore_hint;
> +
In case of nested mutex acquires this will only work for the
inner-most acquire. The problem is a general issue (#2124) we have
with current priority inheritance. I don't think the optimization is
introducing a new priority inversion, but care must be taken when
using nested mutexes until we fix #2124.

Fixing #2124 may be facilitated by the changes made here to add
filters since the filter can update the priority more intelligently
for the nested mutex cases. This probably requires adding multiple
Restore_priority filters.