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.hu...@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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
