taskPrioritySet() don't change the task priority - VxWorks

This is a discussion on taskPrioritySet() don't change the task priority - VxWorks ; VxWorks 5.5 - here is the scenario: (1) a task at priority 100 take a mutex with inherited priority. (2) same task call to taskPrioritySet(0,0) - setting its own priority to 0 (ceiling) - Run at priority 0 as expected. ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: taskPrioritySet() don't change the task priority

  1. taskPrioritySet() don't change the task priority

    VxWorks 5.5 - here is the scenario:

    (1) a task at priority 100 take a mutex with inherited priority.
    (2) same task call to taskPrioritySet(0,0) - setting its own priority
    to 0 (ceiling) - Run at priority 0 as expected.
    (3) same task tries to lower back it's priority to the original
    priority and call taskPrioritySet(0,100) - Run at priority 0 (zero)!!!
    although the return value of taskPrioritySet is OK.

    does anyone knows why?

  2. Re: taskPrioritySet() don't change the task priority

    VxWorks handles priority inheritance in two ways. First the old way.

    Old way. (5.x)
    Each task tracks the total number of inversion safe mutexes it has
    locked. Once this number goes to zero (0), only then will the
    priority be lowered. Easy to implement, but it has the drawback of a
    task remaining at a higher priority longer than may be necessary.

    How does this relate to what your question?
    In this case, the task had its priority bumped to a higher level.
    There are no problems at all in raising the priority more. The issue
    comes in when one tries to lower the priority. If it has any mutex
    locks, the running priority will not change (but its "normal" priority
    will change). Once it gives up its last mutex, its running priority
    should drop to the level of the "normal" priority. Remember, it does
    not track which mutexes it has locked--only the counts. If the
    priority is allowed to drop to an arbitrary level as soon as
    taskPrioritySet() is called, it defeats the purpose of inversion safe
    mutexes.

    New way. (6.x)
    Each task tracks the total number of inversion safe mutexes it has
    locked that have contributed to its priority level being bumped up.
    Although it still has the drawback of a task remaining at a higher
    priority longer than may be necessary, it is for a shorter period of
    time than the "old way". Dropping the priority with taskPrioritySet()
    is a little more complicated than the old way, but similar reasoning
    applies.

    Hope this helps.

    Peter.


    d...@surfpad.net wrote:
    > VxWorks 5.5 - here is the scenario:
    >
    > (1) a task at priority 100 take a mutex with inherited priority.
    > (2) same task call to taskPrioritySet(0,0) - setting its own priority
    > to 0 (ceiling) - Run at priority 0 as expected.
    > (3) same task tries to lower back it's priority to the original
    > priority and call taskPrioritySet(0,100) - Run at priority 0 (zero)!!!
    > although the return value of taskPrioritySet is OK.
    >
    > does anyone knows why?


  3. Re: taskPrioritySet() don't change the task priority

    On Apr 8, 6:25 pm, peter.mit...@gmail.com wrote:
    > VxWorks handles priority inheritance in two ways. First the old way.
    >
    > Old way. (5.x)
    > Each task tracks the total number of inversion safe mutexes it has
    > locked. Once this number goes to zero (0), only then will the
    > priority be lowered. Easy to implement, but it has the drawback of a
    > task remaining at a higher priority longer than may be necessary.
    >
    > How does this relate to what your question?
    > In this case, the task had its priority bumped to a higher level.
    > There are no problems at all in raising the priority more. The issue
    > comes in when one tries to lower the priority. If it has any mutex
    > locks, the running priority will not change (but its "normal" priority
    > will change). Once it gives up its last mutex, its running priority
    > should drop to the level of the "normal" priority. Remember, it does
    > not track which mutexes it has locked--only the counts. If the
    > priority is allowed to drop to an arbitrary level as soon as
    > taskPrioritySet() is called, it defeats the purpose of inversion safe
    > mutexes.
    >
    > New way. (6.x)
    > Each task tracks the total number of inversion safe mutexes it has
    > locked that have contributed to its priority level being bumped up.
    > Although it still has the drawback of a task remaining at a higher
    > priority longer than may be necessary, it is for a shorter period of
    > time than the "old way". Dropping the priority with taskPrioritySet()
    > is a little more complicated than the old way, but similar reasoning
    > applies.
    >
    > Hope this helps.
    >
    > Peter.
    >
    > d...@surfpad.net wrote:
    > > VxWorks 5.5 - here is the scenario:

    >
    > > (1) a task at priority 100 take a mutex with inherited priority.
    > > (2) same task call to taskPrioritySet(0,0) - setting its own priority
    > > to 0 (ceiling) - Run at priority 0 as expected.
    > > (3) same task tries to lower back it's priority to the original
    > > priority and call taskPrioritySet(0,100) - Run at priority 0 (zero)!!!
    > > although the return value of taskPrioritySet is OK.

    >
    > > does anyone knows why?


    Thanks Peter,
    The task take the mutex far away from the point I set the priority.
    The thing is I have to execute some code and at the end of it to wait
    on an empty semaphore, all in one critical section.
    I can't lock tasks switch or take a mutex, because then I'll lock the
    system for good.
    Do you have an idea how can execute this code in sort of critical
    section without tasks ceiling?

    Thanks again,
    Dror.

+ Reply to Thread