Implicit yield in priority inheritance: bug or feature?

[Gedare Bloom]

On Thu, Mar 25, 2021 at 12:39 PM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> Hello,
>
> I specify currently the Classic API semaphore obtain/release behaviour.
> This includes the locking protocol. While testing the MrsP and priority
> inheritance protocols I noticed a strange behaviour. When a thread (the
> blocker) gives its priority to the thread of a semaphore owner, then
> this priority is appended to its priority group. If another with the
> same priority as the blocker is ready, then the semaphore obtain will
> yield the processor to this thread and not the owner of the semaphore.
> To me this looks like a bug. There seems to be no test case for this in
> the test suite. I see no test result changes with this patch:
>
> diff --git a/cpukit/score/src/threadchangepriority.c
> b/cpukit/score/src/threadchangepriority.c
>
> index 13e9147916..824a4c41ab 100644
> --- a/cpukit/score/src/threadchangepriority.c
> +++ b/cpukit/score/src/threadchangepriority.c
> @@ -214,7 +214,7 @@ void _Thread_Priority_perform_actions(
>         the_thread,
>         queue,
>         the_thread->Wait.operations,
> -      false,
> +      true,
>         queue_context
>       );
>
> For MrsP semaphores, this implicit yield is quite bad in some cases,
> since threads blocked on a MrsP semaphore do a busy wait and an implicit
> yield means we could end up in threads doing busy waits instead of
> helping the owner.
>

This is tricky. I had considered this case in the uniprocessor
implementation during the rework to fix the PIP bugs
(https://gedare.github.io/pdf/gadia_verifying_2016.pdf), but we did
not do much to test it or to make any modeling decision about what
should be the correct behavior, in case "Two threads have the same
priority, one has a lower priority than the others." Probably no one
considered this corner case deeply. In general real-time modeling, we
assume one task per priority, while in real systems we allow tasks to
share a priority with the understanding that there is no
prioritization or guarantees among them--the real-time analysis should
treat them as a single group. So in the uniprocessor PIP it doesn't
matter if the inheriting thread runs next or another similarly
high-priority thread runs.

I agree however that the behavior is bad when spinlocks are in use,
and it may be considered a bug in the SMP implementation. Do you know
if any of the academic papers on MrsP address this problem / provide
any guidance for us to consider?

Gedare

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel