On June 25, 2015 7:33:24 PM CDT, Saurabh Gadia <ga...@usc.edu> wrote: >@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.
True recursion? Or implemented with loop? Ok. Still an O(n) operation. Discuss locking on devel@ > >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 --joel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
