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
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 cyrille.ar...@gmail.com wrote:
Hi all,
As I wrote earlier, I think it makes sense to include validate
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
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
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
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
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 ga...@usc.edu wrote:
Hi,
I have implemented
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 ga...@usc.edu wrote:
Hi,
To validate spsem03 test case I created a new test case by modifying
spsem02. Below is the description of
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:
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
: Uniprocessor implementation of nested mutex problem of priority
inversion.
To: Saurabh Gadia ga...@usc.edu
Cc: devel@rtems.org devel@rtems.org
On Thu, Aug 13, 2015 at 6:55 PM, Saurabh Gadia ga...@usc.edu wrote:
How can we get mutex-queue.priority_before data structure without having
, 2015 at 8:01 AM, Saurabh Gadia ga...@usc.edu wrote:
Thanks,
Saurabh Gadia
-- Forwarded message --
From: Gedare Bloom ged...@rtems.org
Date: Thu, Aug 13, 2015 at 12:51 PM
Subject: Re: Uniprocessor implementation of nested mutex problem of priority
inversion.
To: Saurabh
...@rtems.org javascript:;
Date: Thu, Aug 13, 2015 at 4:32 PM
Subject: Re: Uniprocessor implementation of nested mutex problem of
priority
inversion.
To: Saurabh Gadia ga...@usc.edu javascript:;
Cc: devel@rtems.org javascript:; devel@rtems.org javascript:;
On Thu, Aug 13, 2015 at 6
On Thu, Aug 13, 2015 at 6:55 PM, Saurabh Gadia ga...@usc.edu 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.
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
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,
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 ga...@usc.edu wrote:
Hi,
Following is the result of spsem04 test
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,
19 matches
Mail list logo
