Patch for "strict order mutex"

[xi yang]

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.

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
> >>
> >>
> >
> >
>
>