@joel: It essentially means finding out the highest priority thread (or ceiling) of any remaining mutex held, right? If you are talking this in context of nested mutex problem ---> We never go and find the highest priority thread waiting on held mutex. Inversely highest priority thread will recursively make changes to top of stack of held mutexes by the holder. We don't search.
Thanks, Saurabh Gadia On Thu, Jun 25, 2015 at 5:27 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > On June 25, 2015 7:23:06 PM CDT, Cyrille Artho <cyrille.ar...@gmail.com> > wrote: > >Hi Gedare and all, > >Good news: > >In this morning's discussion, we fixed some remaining issues in the > >model and now got results. > > > >The current model shows a case of priority inversion with a simple > >priority reset mechanism and the absence of that problem with the > >proposed strategy. > > > >There is only one flaw: We had to use a global lock in the model > >(essentially making the entire "lock" and "unlock" operations atomic), > >because so far we couldn't find a way to secure lock the operations on > >a lower level. The model uses a list of locks held (by a thread) and a > >list of threads waiting on a lock (in the lock data structure), so > >these aspects are essentially cross-cutting and very hard to get right > >without a global lock. > > > >The RTEMS code uses different macros inside these operations (_Seize, > >_Surrender), which do not seem to use a global lock (but I may have > >missed something). It is possible that a data race occurs for a > >complex lock update strategy, if we don't use a global lock. > > > >Saurabh will clean up the model and provide documentation with details. > > > >In the meantime, can you maybe answer these questions for us: > > > >(1) Did you have any issues with race conditions in the current RTEMS > >code (especially recent changes)? > > We haven't observed any but that doesn't mean there aren't any > undiscovered. > > >(2) Is a fix using a global lock acceptable? Correctness-wise it's the > >safest thing, but of course performance-wise it's a bottleneck. > > The locking strategy needs to be discussed. On a uniprocessor system, > these issues tend to be minor and cause delays. On smp systems, they become > more complex and performance problems. > > It essentially means finding out the highest priority thread (or ceiling) > of any remaining mutex held, right? > > Bring this up on devel@ > > > --joel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
