Ok. should I will have complete trace files on drive. okkk.. I will upload the trace and then mention about why we got error and how we solved the problem of unbounded priorities.
Thanks, Saurabh Gadia On Thu, Jun 25, 2015 at 5:40 PM, Cyrille Artho <cyrille.ar...@gmail.com> wrote: > Yes, let's discuss this in more depth on the devel list. > > Saurabh can clean up the code a bit first and prepare a summary of the > error trace. The detailed trace can be posted on Google docs, and > Saurabh can post a message describing the issue and a link to the doc > on the mailing list. > > On Fri, Jun 26, 2015 at 9:35 AM, Joel Sherrill > <joel.sherr...@oarcorp.com> wrote: > > > > > > 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 > > > > -- > Regards, > Cyrille Artho >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
