SMP Next Steps

[Gedare Bloom]

Thank you for the update and great progress. The plan to resolve MrsP
issues looks sound.

On Wed, Sep 21, 2016 at 8:15 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello,
>
> with the reworked thread priority management we have now all information
> available to feed the schedulers and implement the last step of the OMIP
> locking protocol.
>
> https://devel.rtems.org/ticket/2556
>
> The remaining work is mostly SMP only. We have two major locking domains for
> threads, one is the thread wait domain (thread queues) and the other is the
> thread state (scheduler related) domain. The thread wait domain needs to
> pass the thread priority information to the thread state domain. This will
> be done via a dedicated low-level SMP lock (Thread_Control::Scheduler::Lock)
> and disabled thread dispatching. Each thread may use multiple scheduler
> instances (clustered scheduling) due to the locking protocols (MrsP and
> OMIP).
>
> The first approach to implement MrsP had several severe design flaws. I will
> replace it and use a thread queue instead. So, the Resource Handler will be
> removed entirely
> (https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/resource.h).
> The first scheduler helping protocol used a return value to indicate threads
> in need for help. There are three problems with this approach. Firstly, you
> can return at most one thread, but multiple threads in need for help may be
> produced by one operation, e.g. due to affinity constraints. Secondly, the
> thread the initiated the operation must carry out the ask for help
> operation. This is bad in terms of scheduler instance isolation, e.g. high
> priority thread H in instance A sends a message to worker thread in instance
> B, H must execute scheduler code of instance B. Thirdly, it complicates the
> SMP low-level locking. I will change this to use an SMP message processed
> via an inter-processor-interrupt.
>
> Once the OMIP implementation is done, the SMP support for RTEMS is feature
> complete from my point of view. There are still some interesting things to
> do, but the ground work is done and I think we have a state-of-the-art
> feature set in real-time SMP systems area.
>
> --
> 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.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel