Re: Results

I will try to model this test case environment soon and get back to you. @gedare - you are absolutely correct about the description of project On Friday, June 26, 2015, Gedare Bloom wrote: > On Fri, Jun 26, 2015 at 9:42 AM, Sebastian Huber > > wrote: > > On 26/06/15 15:28, Gedare Bloom wrote: >

Re: Results

On Fri, Jun 26, 2015 at 9:42 AM, Sebastian Huber wrote: > On 26/06/15 15:28, Gedare Bloom wrote: >> >> Since this thread got migrated to devel a bit prematurely, I'll >> back-stop some of the details and how I understand the state of this >> project. >> >> Saurabh is working toward solving https:/

Re: Results

On 26/06/15 15:28, Gedare Bloom wrote: Since this thread got migrated to devel a bit prematurely, I'll back-stop some of the details and how I understand the state of this project. Saurabh is working toward solving https://devel.rtems.org/ticket/2124 (so yes there is a ticket already, and it sh

Re: Results

Since this thread got migrated to devel a bit prematurely, I'll back-stop some of the details and how I understand the state of this project. Saurabh is working toward solving https://devel.rtems.org/ticket/2124 (so yes there is a ticket already, and it should be referenced by patches accordingly

Re: Results

On 26/06/15 02:33, Saurabh Gadia 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.

Re: Results

You can configure the test environment according to your needs but 3 mutex are sufficient to cover all test cases and we can have multiple threads using verify() of JPF. Thanks, Saurabh Gadia On Thu, Jun 25, 2015 at 6:37 PM, Saurabh Gadia wrote: > Hi all, > For time being I have cleaned up the

Re: Results

Hi all, For time being I have cleaned up the code. I have also attached the trace files where our JPF-Model can reproduce the RTEMS unbounded priority inheritance problem(TraceWupi). And after running it through solution model we are able to demonstrate that there are no assertion errors and it run

Re: Results

O(n) is the least that we can have!! Thanks, Saurabh Gadia On Thu, Jun 25, 2015 at 5:39 PM, Saurabh Gadia wrote: > I mean not recursion. just looping till top of stack of held mutexes. > check this out: > https://github.com/saurabhgadia4/lock-model/blob/master/rtems/Mutex.java > -->updateRecPr

Re: Results

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 wrote: > Yes, let's discuss this in more dep

Re: Results

I mean not recursion. just looping till top of stack of held mutexes. check this out: https://github.com/saurabhgadia4/lock-model/blob/master/rtems/Mutex.java -->updateRecPriority() line 143 Thanks, Saurabh Gadia On Thu, Jun 25, 2015 at 5:35 PM, Joel Sherrill wrote: > > > On June 25, 2015 7:33

Re: Results

On June 25, 2015 7:33:24 PM CDT, Saurabh Gadia 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 wai

Re: Results

@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 recursi