rsive mutex acquisition behavior for
supporting horizontal nesting? Will it be fine with RTEMS?
note: *Cyrille* please mention any other doubts if I have missed any.
Thanks,
Saurabh Gadia
On Sun, Sep 6, 2015 at 11:04 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hell
/saurabhgadia4/rtems/tree/nested-mutex
Thanks,
Saurabh Gadia
From ffe654a71bbe6eab9002499a245e023a4a08e5c1 Mon Sep 17 00:00:00 2001
From: Saurabh
Date: Fri, 4 Sep 2015 16:27:31 -0700
Subject: [PATCH] Complete Nested Mutex patch for solving priority inversion
problem in uniprocessor architecture
();
_ISR_Disable( level );
}
So while waiting it gives up the processor periodically if lock is not
available. Hope this helps.
Thanks,
Saurabh Gadia
On Fri, Aug 21, 2015 at 11:18 PM, Chan Kim wrote:
> Hello,
> This is a very basic question and I guess something's
y we can do that. We don't need to change any
design for this nor need to do any bookkeeping thing.
Thanks,
Saurabh Gadia
On Sun, Aug 16, 2015 at 6:48 PM, Gedare Bloom wrote:
> We will rely on the linker should not pull the function in if unused.
> So if it is only referenced by te
this
_Thread_Validate_Priority.
Thanks,
Saurabh Gadia
On Fri, Aug 14, 2015 at 10:06 AM, Saurabh Gadia wrote:
> 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
mpted ( To acheive this behavior I guess we will need to make
change to core_mutex_surrender).
Thanks,
Saurabh Gadia
On Fri, Aug 14, 2015 at 9:43 AM, Saurabh Gadia wrote:
> When a thread releases a semaphore/mutex we call this validate method to
> make sure that there does not exists a
parate call from user level
but then we need to make sure that the thread dispatch mechanism is
disabled. If not then whether including this validate method in
_CORE_mutex_Surrender for only strict_order_mutex and Priority inheritance
attribute is feasible or not.
Please guide me on this.
Thanks,
on release.
> > One data structure contains threads, the other one locks; it is not
> > possible to eliminate one of them (at least not without a major
> > redesign of all the other code).
> >
> > On Fri, Aug 14, 2015 at 8:34 AM, Saurabh Gadia > wrote:
> >>
> >
rol and then we traverse upto the head of the chain to manipulate
the priority_before if required.
Thanks,
Saurabh Gadia
On Thu, Aug 13, 2015 at 12:51 PM, Gedare Bloom wrote:
> Saurabh,
>
> Remove the commit "Updated the motivation for creating the new
> branch", don&#
=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing
Thanks,
Saurabh Gadia
On Thu, Aug 13, 2015 at 9:10 AM, Saurabh Gadia wrote:
> 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&
hanks,
Saurabh Gadia
On Thu, Aug 13, 2015 at 9:08 AM, Gedare Bloom wrote:
> 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
: suspending
TA01: priority 36
TA01: exiting
*** END OF TEST SPSEM 4 ***
You can see the difference in highlighted portions of both outputs.
Thanks,
Saurabh Gadia
On Thu, Aug 13, 2015 at 8:17 AM, Saurabh Gadia wrote:
> Ok. I will mail you back soon.
>
>
> On Thursday, August 13,
on a branch.
>
> Gedare
>
> On Thu, Aug 13, 2015 at 5:28 AM, Saurabh Gadia > wrote:
> > 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
&g
]
So this is sufficient to prove that spsem03 test passes as we just modelled
it above.
Thanks,
Saurabh Gadia
On Thu, Aug 13, 2015 at 2:28 AM, Saurabh Gadia wrote:
> Hi,
>
> I have implemented uniprocessor model of nested mutex problem in rtems.
> its still in basic form
=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
so is there a
way to get Object from its id. But its again convoluted problem - how to
get id?
Thanks,
Saurabh Gadia
On Thu, Aug 13, 2015 at 12:20 AM, Saurabh Gadia wrote:
> Hi,
>
> For a given thread waiting on a mutex, how can we extract the
> mutex_control on which this thread
Hi,
For a given thread waiting on a mutex, how can we extract the mutex_control
on which this thread is waiting? For example in Thread_Change_priority().
So do the thread_control structure has any reference to mutex on which it
is blocked?
Thanks,
Saurabh Gadia
acquired for SMP.
But how are both macros different. With former Macro it disables all
interrupts as level is highest but how does it ensure
thread_dispatch_disable?
Thanks,
Saurabh Gadia
On Wed, Aug 12, 2015 at 9:52 AM, Gedare Bloom wrote:
> On Wed, Aug 12, 2015 at 11:48 AM, Saurabh Ga
ected mode because we
are sure that ISR will not affect the operation and with protected ISR may
affect the operation so we guard operation against it. When is protected
and unprotected used in respect with the context?
Thanks,
Saurabh Gadia
___
devel mailing
Hi,
how should I make sure that testcases I am implementing are running under
uniprocessor configuration?
What do we have to do to run rtems for uniprocessor architecture?
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http
For surrender we don't disable thread dispatching for uniprocessor. So is
that the thread can be interleaved?
Thanks,
Saurabh Gadia
On Wed, Aug 5, 2015 at 9:01 AM, Gedare Bloom wrote:
> These functions are called with interrupts disabled. However,
> _CORE_mutex_Seize_interru
Hi,
So on uniprocessor can we assume that a thread calling
_CORE_mutex_Seize_body or _CORE_mutex_Surrender never gets preempted or
interleaved as if it holds a global lock. Whcih means that we can create a
JPF model for same using global lock.
Thanks,
Saurabh Gadia
release and
before checking my_generation==the_thread->priority_generation by some
other thread.
Thanks,
Saurabh Gadia
On Mon, Jul 27, 2015 at 9:10 AM, Saurabh Gadia wrote:
> hi,
>
> I was going through the code in _thread_change_priority(){..}
> (threadchangepriority.c) and ha
;Wait.operations->priority_change )(
the_thread,
new_priority,
the_thread->Wait.queue
);
how is the data race problem avoided while setting
the_thread->priority_generation?
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.o
Hi,
To avoid data race I need cmp_swap(). So is there some implementation in
java to imitate that. And for rtems which method we use for that?
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
ault in
threadimpl.h?
Thanks,
Saurabh Gadia
On Thu, Jul 23, 2015 at 7:38 PM, Saurabh Gadia wrote:
> Yes. I guess I was right about the data race problem we are facing in our
> model. It is also present in rtems:
> _Thread_queue_Extract_locked( &the_mutex->Wait_queue, the_
As per thread initialization in threadinitialize.c we should acquire
default lock i.e the_thread->Lock.Default. Am I right?
Thanks,
Saurabh Gadia
On Thu, Jul 23, 2015 at 6:58 PM, Saurabh Gadia wrote:
> basically every time we try to acquire mutex there should be lock
> acquisitio
basically every time we try to acquire mutex there should be lock
acquisition related executing thread.
Thanks,
Saurabh Gadia
On Thu, Jul 23, 2015 at 6:47 PM, Saurabh Gadia wrote:
> hi,
>
>
> Scenario:
> thread t1: current_priority = 5, mutex acquired = m1, m2
> thread t2
thread when holder==NULL in
1st code snippet.
Am I right? or is there something I am missing?
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
-model/blob/rtemsjpf-0.4/rtems/Mutex.java
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hi,
I have just implemented global lock free nested mutex JPF model for SMP
arch also.
github JPF link:
https://github.com/saurabhgadia4/lock-model/tree/rtemsjpf-0.6-global-free
please review the model and give your feedback!!
Thanks,
Saurabh Gadia
Yes I was looking for same present in Thread_Lock_control. I might some how
missed it while going through Thread_Control_struct. Thanks. Then as lock
is present then I suppose we might have certainly taken care of data race
conditions.
Thanks,
Saurabh Gadia
On Thu, Jul 16, 2015 at 12:19 AM
lem. So for SMP we just have to overcome the data race
that might happen while modifying thread->real_priority.
Thanks,
Saurabh Gadia
On Wed, Jul 15, 2015 at 4:49 PM, Saurabh Gadia wrote:
> Hi,
> Is there any explicit locking to avoid data races condition on members of
> Threa
*thread->current_priority.
*As it is updated by thread while restoring its priority and while some
other thread trying to promote for nested_mutex behavior.
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listi
1-16
> > Fax : +49 89 189 47 41-09
> > E-Mail : sebastian.hu...@embedded-brains.de
> > PGP : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
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 clea
es to acquire
the same mutex. The updatePriority() in lock() and waitqueue.Remove()
happens simultaneously. We solved this by having the global lock() for each
mutex. (May be Cyrille can elaborate on this)
Thanks,
Saurabh Gadia
On Thu, Jun 25, 2015 at 5:43 PM, Saurabh Gadia wrote:
> O(n) is the
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/M
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
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 Jun
ill recursively make changes to top of
stack of held mutexes by the holder. We don't search.
Thanks,
Saurabh Gadia
On Thu, Jun 25, 2015 at 5:27 PM, Joel Sherrill
wrote:
>
>
> On June 25, 2015 7:23:06 PM CDT, Cyrille Artho
> wrote:
> >Hi Gedare and all,
> >Good news:
>
ems
wiki link: https://devel.rtems.org/wiki/GSoC/2015/NestedMutex
I feel like I should implement my solution very soon along with progressing
on JPF and check if expected output is achieved or not.
Thanks,
Saurabh Gadia
On Fri, Jun 5, 2015 at 1:42 PM, Saurabh Gadia wrote:
> Hi,
> insta
Hi,
installing pax work. But you have to again do the bootstrap step,
configuration and compiling.
Thanks.
Thanks,
Saurabh Gadia
On Fri, Jun 5, 2015 at 12:44 PM, Gedare Bloom wrote:
> I'm not really sure, but I think you probably have to re-run configure.
>
> On Fri, Jun 5, 2
; This is a current problem in RTEMS. You need to have 'pax' installed
> on your development host to build the dl tests. So, it looks good to
> me!
>
> Gedare
>
> On Thu, Jun 4, 2015 at 9:16 PM, Saurabh Gadia > wrote:
> > I am sorry for not attaching the pat
I am sorry for not attaching the patch and configuration command:
../rtems/configure --target=sparc-rtems4.11 --enable-rtemsbsp=sis
--enable-tests --disable-posix ENABLE_STRICT_ORDER_MUTEX=1
Thanks,
Saurabh Gadia
On Thu, Jun 4, 2015 at 6:08 PM, Saurabh Gadia wrote:
> Hi,
> I work
e[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c'
make: *** [all-recursive] Error 1
saurabh@saurabh-Inspiron-N5010:~/dev1/kernel/b-sis$ ls
'''
I am not able to find dl-tar.c but we have dl-tar.Po. Can anyone guide me
on
I wanted to test the ENABLE_STRICT_ORDER_MUTEX=1 related sptests for
"nested mutex" GSOC project. So please let me know what can be done.
Thanks,
Saurabh Gadia
On Sun, May 31, 2015 at 9:33 PM, Saurabh Gadia wrote:
> Hi,
> so I am working for sparc-sis setting and master branch
it/../../../sis/lib/include/rtems/score/threadimpl.h:394:6: note:
declared here
void _Thread_Change_priority(
^
make[6]: *** [src/libscore_a-coremutexsurrender.o] Error 1
Thanks,
Saurabh Gadia
On Sun, May 31, 2015 at 8:25 PM, Nick Withers
wrote:
> Does re-running bootstrap in the s
The problem is on master branch
Thanks,
Saurabh Gadia
On Sun, May 31, 2015 at 4:44 PM, Saurabh Gadia wrote:
> Logs:
>
> make[6]: Entering directory
> `/home/saurabh/dev1/kernel/b-sis/sparc-rtems4.11/c/sis/cpukit/score'
> make[6]: *** No rule to make target `src/apimutexis
arc-rtems4.11/c/sis/cpukit/score'
make[5]: *** [all-recursive] Error 1
...
There is no makefile but I am also not able to find apimutexislocked.c
How do I proceed about this.
Th
n be accomplished within GSOC
timeline. I also wanted a brief overview on what work is done for debug
support and what future advancement are planned.
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
proposal and what changes are
required to it. I am also attaching a copy of proposal with this mail.
Thanks,
Saurabh Gadia
GSOC2015_GADIA_NestedMutexes.docx
Description: MS-Word 2007 document
___
devel mailing list
devel@rtems.org
http
Thanks for help.
Thanks,
Saurabh Gadia
On Mon, Mar 23, 2015 at 11:07 AM, Joel Sherrill
wrote:
>
>
> On March 23, 2015 10:18:54 AM CDT, Saurabh Gadia wrote:
> >How can insert an entry into this table -
> >https://devel.rtems.org/wiki/GSoC/2015.
>
> You have to regis
How can insert an entry into this table -
https://devel.rtems.org/wiki/GSoC/2015.
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
54 matches
Mail list logo
