Hello Saurabh,
I created a ticket to document some requirements for a mutex
implementation. Its not complete and just a starting point:
https://devel.rtems.org/ticket/2412
On 17/08/15 07:45, Saurabh Gadia wrote:
For every mutex held by a thread it is not feasible to have reference
to CORE_mu
For every mutex held by a thread it is not feasible to have reference to
CORE_mutex_order_list of all mutex that it holds.
* I feel that current solution with CORE_mutex_order_list as argument is
the best choice to have as it is O(1) operation and needs no extra
bookkeeping for the thread.*
In JPF
We will rely on the linker should not pull the function in if unused.
So if it is only referenced by test code, this solution may be fine.
Gedare
On Sun, Aug 16, 2015 at 7:50 PM, Cyrille Artho wrote:
> Hi all,
> As I wrote earlier, I think it makes sense to include validate but
> compile it cond
Hi,
I have implemented the validate method. following are the links for it:
github: https://github.com/saurabhgadia4/rtems/tree/nested-mutex
commit:
https://github.com/saurabhgadia4/rtems/commit/e7f0f169c056076c46ef5ea17b0c38efe33fe576
I am waiting on the decision of how to integrate call to this
And in respect of efficiency, we have to traverse through all the mutex
held my the thread and do the checking. There is no other way to confirm
that priority inversion has occurred or not. One way we can do is have
default argument variable for core_mutex_surrender but then there is change
in API
When a thread releases a semaphore/mutex we call this validate method to
make sure that there does not exists any priority inversion. Following is
the course of action that needs to be performed:
1. Validate method needs to be called within mutex_surrender method because
after releasing a mutex a
> Thanks,
> >>
> >> Saurabh Gadia
> >>
> >> ------ Forwarded message --
> >> From: Gedare Bloom >
> >> Date: Thu, Aug 13, 2015 at 4:32 PM
> >> Subject: Re: Uniprocessor implementation of nested mutex problem of
> pr
From: Gedare Bloom
>> Date: Thu, Aug 13, 2015 at 4:32 PM
>> Subject: Re: Uniprocessor implementation of nested mutex problem of priority
>> inversion.
>> To: Saurabh Gadia
>> Cc: "devel@rtems.org"
>>
>>
>> On Thu, Aug 13, 2015 at 6:55 PM, Saurab
rmation hiding
and interface creep.
Gedare
> On Fri, Aug 14, 2015 at 8:01 AM, Saurabh Gadia wrote:
>>
>> Thanks,
>>
>> Saurabh Gadia
>>
>> -- Forwarded message ------
>> From: Gedare Bloom
>> Date: Thu, Aug 13, 2015 at 12:51 PM
On Thu, Aug 13, 2015 at 6:55 PM, Saurabh Gadia wrote:
> How can we get mutex->queue.priority_before data structure without having
> the mutex structure. We need that to change the priority_before for every
> acquired mutex by a thread to ensure that there is proper stepdown of
> priority. We just
How can we get mutex->queue.priority_before data structure without having
the mutex structure. We need that to change the priority_before for every
acquired mutex by a thread to ensure that there is proper stepdown of
priority. We just need to have mutex to get the start point of the
chain_control
Saurabh,
Remove the commit "Updated the motivation for creating the new
branch", don't add the .tags files, and don't add the .m4 changes that
are not related to your project.
Switch to using RTEMS_CONTAINER_OF macro and remove the typeaddr one.
coremutexseize.c : remove the modification where y
Hi,
I have created a new branch for uniprocessor solution of priority inversion
problem caused by nested mutex behavior.
link: https://github.com/saurabhgadia4/rtems/tree/nested-mutex
test case results:
https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2
That is how we were doing in JPF. The validate method was triggered after
every release of mutex by any thread and we would check for all the waiting
threads on mutex's held by the holder. And if it finds a thread with higher
priority blocked then it would panic or give assertion failure.
Thanks,
Thanks. Would it be possible for you to turn the failure cases into
real test failures? In other words, add some logic to detect the
priority inversion and abort the test?
Gedare
On Thu, Aug 13, 2015 at 12:05 PM, Saurabh Gadia wrote:
> Hi,
>
> Following is the result of spsem04 test without the
Hi,
Following is the result of spsem04 test without the patch:
*** BEGIN OF TEST SPSEM 4 ***
init: S0 created
init: S1 created
init: TA01 created with priority 36
init: TA02 created with priority 34
init: TA03 created with priority 32
TA01: started with priority 36
TA01: priority 36, holdi
Ok. I will mail you back soon.
On Thursday, August 13, 2015, Gedare Bloom wrote:
> Saurabh,
>
> Please pull from rtems.git again, create a new branch from 'master',
> and apply your changes to the branch. It's too hard to review code
> that is not all by itself on a branch.
>
> Gedare
>
> On Thu
Saurabh,
Please pull from rtems.git again, create a new branch from 'master',
and apply your changes to the branch. It's too hard to review code
that is not all by itself on a branch.
Gedare
On Thu, Aug 13, 2015 at 5:28 AM, Saurabh Gadia wrote:
> Hi,
>
> I have implemented uniprocessor model of
Can you please print the output from spsem04 without strict-order
enabled? (Or, without your patches to fix it?)
On Thu, Aug 13, 2015 at 6:31 AM, Saurabh Gadia wrote:
> Hi,
>
> To validate spsem03 test case I created a new test case by modifying
> spsem02. Below is the description of the new test
Hi,
To validate spsem03 test case I created a new test case by modifying
spsem02. Below is the description of the new test case:
Task: TA01 having priority 36, TA02 having priority 34, TA03 having
priority 32.
Throughout the course following actions are performed:
TA01 acquires S0
TA02 acquires
Hi,
I have implemented uniprocessor model of nested mutex problem in rtems. its
still in basic form. I tried to multiplex it with the existing solution but
was finding hard time. To push ahead, I decided to have separate functions
for uniprocessor and SMP(kept default behavior) and with your revie
21 matches
Mail list logo
