Patch for "strict order mutex"

[xi yang]

2007/10/19, Joel Sherrill <joel.sherrill at oarcorp.com>:
> xi yang wrote:
> > Hi joel,ray
> >
> > 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.
> >
>
> You can do a "cvs diff -u" in any checked out cvs tree and it
> will be ONLY the changes you made since that code was checked
> out.
>
> The resulting diff may or may not apply cleanly to the CVS head.
>
> You can do a "cvs update -Pd" on your checked out tree.  If there
> are conflicts between your edits and any edits since your original
> check out, cvs will flag them for you to fix.
cvs update -Pd
cvs diff -uN
Got the patch in attachment and the .tar of files of sp36 also in attachment.
Thanks Joel , Ray
Regards.
>
>
> Most of your changes are probably in places that didn't change
> so a diff from the old cvs check out will probably be updated
> fine.
> > Regards.
> >
> > 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 4.7.99.2) 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
> >> appears
> >> 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
> >> think
> >> 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"
> >>
> >> --joel
> >>
> >>> ------------------
> >>> 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
> >>>>
> >>>>
> >>>>
> >>>
> >>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strict_order_mutex.patch
Type: text/x-patch
Size: 11256 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20071020/902f09ab/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sp36.tar
Type: application/x-tar
Size: 20480 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20071020/902f09ab/attachment.tar>