Implicit yield in priority inheritance: bug or feature?

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Mar 25 18:39:07 UTC 2021


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.

-- 
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/



More information about the devel mailing list