priority inheritance (Tornado 202) - VxWorks

This is a discussion on priority inheritance (Tornado 202) - VxWorks ; Hi I have noticed a problem in an old system I inherited. Can someone please explain this to me: I have task A (priority 130) owns a semaphore, task B (priority 110) tries to get the semaphore, priority of task ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: priority inheritance (Tornado 202)

  1. priority inheritance (Tornado 202)

    Hi

    I have noticed a problem in an old system I inherited. Can someone please
    explain this to me:

    I have task A (priority 130) owns a semaphore, task B (priority 110)
    tries to get the semaphore, priority of task A is increased to the
    priority of task B, now task C (priority 90) tries to get the semaphore,
    now A is elevated to C's priority. When A finishes with the semaphore,
    and C grabs it. I expected A to lose its temporary high priority but that
    is not what I am seeing. Shouldn't A lose its priority after releasing
    the semaphore? What can cause A to stay at the temporary high priority?

    Many thanks.


  2. Re: priority inheritance (Tornado 202)

    On Fri, 04 Jul 2008 20:42:36 -0500, redjupiter wrote:

    > Hi
    >
    > I have noticed a problem in an old system I inherited. Can someone
    > please explain this to me:
    >
    > I have task A (priority 130) owns a semaphore, task B (priority 110)
    > tries to get the semaphore, priority of task A is increased to the
    > priority of task B, now task C (priority 90) tries to get the semaphore,
    > now A is elevated to C's priority. When A finishes with the semaphore,
    > and C grabs it. I expected A to lose its temporary high priority but
    > that is not what I am seeing. Shouldn't A lose its priority after
    > releasing the semaphore? What can cause A to stay at the temporary high
    > priority?
    >
    > Many thanks.


    In the manual it says:

    Once the task priority has been elevated, it remains at the
    higher level until all mutual-exclusion semaphores that have contributed
    to thetasks elevated priority are released. Hence, the inheriting task is
    protected from preemption by any intermediate-priority tasks. This option
    must be used in conjunction with a priority queue (SEM_Q_PRIORITY).


    Does this means, That will stay at high priority until all tasks released
    the semaphore or when A releases all semaphore(s) it owns?

    thanks

  3. Re: priority inheritance (Tornado 202)

    redjupiter escribió:
    > On Fri, 04 Jul 2008 20:42:36 -0500, redjupiter wrote:
    >
    >> I have noticed a problem in an old system I inherited. Can someone
    >> please explain this to me:
    >>
    >> I have task A (priority 130) owns a semaphore, task B (priority 110)
    >> tries to get the semaphore, priority of task A is increased to the
    >> priority of task B, now task C (priority 90) tries to get the semaphore,
    >> now A is elevated to C's priority. When A finishes with the semaphore,
    >> and C grabs it. I expected A to lose its temporary high priority but
    >> that is not what I am seeing. Shouldn't A lose its priority after
    >> releasing the semaphore? What can cause A to stay at the temporary high
    >> priority?
    >>

    >
    > In the manual it says:
    >
    > Once the task priority has been elevated, it remains at the
    > higher level until all mutual-exclusion semaphores that have contributed
    > to thetasks elevated priority are released. Hence, the inheriting task is
    > protected from preemption by any intermediate-priority tasks. This option
    > must be used in conjunction with a priority queue (SEM_Q_PRIORITY).
    >
    > Does this means, That will stay at high priority until all tasks released
    > the semaphore or when A releases all semaphore(s) it owns?


    AFAIK, semaphores are independent entities: thay are not "owned" by a task.

    In your case, A will return to B's priority when C releases the
    semaphore. At least, that is what it should be, IMHO.


  4. Re: priority inheritance (Tornado 202)

    > AFAIK, semaphores are independent entities: thay are not "owned" by a task.
    >
    > In your case, A will return to B's priority when C releases the
    > semaphore. At least, that is what it should be, IMHO.


    In VxWorks, only mutex semaphores allow priority inheritance. To be
    honest, I don't know if the new reader-writer semaphores in 6.6 allow
    it or not, but for the purposes of this post, that does not matter.
    For the remainder of this post, unless otherwise specified, assume
    that all mutex semaphores are inversion safe (though in practice one
    must explicitly set the option).

    One may argue that ideally, when the inherited priority level is
    lowered, it will be done in a step-wise fashion. That is, as each
    dependency that caused the priority level to be bumped up is removed,
    the inherited priority level should drop down to the priority level of
    the highest remaining dependency. Gawd, I get too wordy sometimes.
    Example ... task A (pri 100 bumped up to 80) has two mutexes (X & Y)
    that tasks B (pri 90) and task C (pri 80) are respectively pending
    for. When task A gives up mutex Y to task C, we might expect that its
    priority will drop to 90. When it finally gives up mutex X to task B,
    we would expect its priority level to drop back to 100.

    Priority inheritance does not work that way in VxWorks.

    Here is how it used to work (before 6.0).

    The priority level remains "bumped up" until the task that has the
    lock on the mutex semaphore gives up its last inversion safe mutex
    semaphore. Using the example from above, when task A gives up mutex Y
    to task C, its priority remains at 80. After it gives up mutex X to
    task B, then its priority will drop back to 100 (skipping 90). Let's
    throw curve ball #1 into the mix. What if task A had a lock on mutex
    Z while all this was going on, but no one was pending on Z? In that
    case, the priority level will remain at 80 until Z is given up--then
    it will drop back to 100.

    Why do it this way? It's simple, and for most cases, it is good
    enough. However, it does mean that when "curve ball #1" comes into
    play, the priority will remain higher for a longer period of time than
    is necessary (or wanted).

    As of VxWorks 6.0, the algorithm changed. The priority level now
    remains elevated until the task that has the lock on the mutex
    semaphore gives up its last inversion safe mutex that contributed to
    raising the priority level. This improvement avoids the problem of
    "curve ball #1". It does have its own limitations. For example, if
    task B and/or task C time(s) out while waiting for task A to give up
    the semaphores, task A's priority level does not get recalculated
    until later. If I remember correctly, "later" is when it tries to
    give up the semaphore.

    Some years ago, I explored various methods to allow the step-wise
    lowering of priority levels. It was doable, but the solutions had
    undesirable impacts upon memory usage, and/or determinism--two
    criteria that were considered very important.

    pcm


+ Reply to Thread