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.hu...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel