Patch for "strict order mutex"
hiyangxi at gmail.com
Fri Oct 19 15:40:12 UTC 2007
Sorry, that's my fault, I worked based a CVS version , and I don't
know how to get
that copy from CVS,so the patch is so big.
I will get the current version and then changed the souce of it ,then
diff with this
current version tomorrow.
2007/10/19, Joel Sherrill <joel.sherrill at oarcorp.com>:
> Ray wrote:
> > Thanks for your work. But pls compress your patch file before send to the maillist.
> > And I believe that you did not make the right patch in the attachment. It is hard to merge a patch file of 81,000 lines. It is a better idea to make a diff base on a freeze version (e.g. version 4.7.1 or CVS snapshot 220.127.116.11) because CVS is a moving target. It has to keep in mind that the patch should only contain your changes.
> Diffing this type of code against CVS isn't a big deal. Usually it is
> actually easier
> for me to merge a patch against CVS than an older released version.
> But this patch wasn't generated in a way to be easy to deal with. It
> to be a diff -uNr of a modified old tarball versus a fresh CVS checkout.
> Merge your change into the fresh CVS and then do this from the top:
> cvs diff -uN
> If you added a file, there are techniques to deal with that so cvs will
> you added it locally. But for now, just send those separate from the
> main diff.
> Always update your cvs tree before doing a diff for submission.
> It really is easier for me if you make a diff against the RTEMS version you
> will merge into. Most of the time this is against the CVS head. Make your
> diff's to that and keep your local cvs up to date with "cvs up -Pd"
> > ------------------
> > Thanks & Best Regards!
> > Ray
> > 2007-10-19
> > -------------------------------------------------------------
> > From: xi yang
> > Date: 2007-10-19 02:15:49
> > To: RTEMS Users; Joel Sherrill
> > CC:
> > Sub: Patch for "strict order mutex"
> >> 1)What's strict order mutex ?
> >> In rtems,when a task release a priority_inheritance or
> >> priority ceiling semaphore,the kernel detect whether
> >> this task holds priority_inheritance or priority
> >> ceiling semaphore, if not, set the priority of task
> >> back to real priority of task.
> >> This method is right, but in theory, we would like
> >> to reset the priority after releasing the mutex if
> >> releasing it in LIFO order.Do it like this can decrease
> >> the blocking time of a higher priority task .
> >> 2)How to enable "strict order mutex " ?
> >> When configuring the rtems , add
> >> ENABLE_STRICT_ORDER_MUTEX=1
> >> to your configure parameter.
> >> I add sp36 to test the function of "strict order mutex"
> >> 3)About this test program
> >> T0,T1,S0,S1
> >> T0,priority 4
> >> T1,priority 1
> >> S0,priority inheritance
> >> S1,priority ceiling,priority ceiling 2
> >> 1,T0 obtain S0 then obtain S1, priority of T0 should be improved to 2
> >> 2,T0 try to release S0, but not in strict order, return error code
> >> 3,T0 release S1,the priority of T0 back to 4
> >> 4,T1 try to obtain S0
> >> 5,T1 should be blocked and the priority of T0 should be improved to 1
> >> 6,T0 release S0
> >> 7,T1 obtain S0
> >> 8,OVER.
> >> I test it under bochs , this patch is for rtems that check form CVS as
> >> cvs -d :pserver:anoncvs at www.rtems.com:/usr1/CVS -z 9 co
> >> -rrtems-4-8-branch rtems
> >> Regards.
> >> _______________________________________________
> >> rtems-users mailing list
> >> rtems-users at rtems.com
> >> http://rtems.rtems.org/mailman/listinfo/rtems-users
More information about the users