• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1220 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Question about priority inheritance semaphores

user6284023
Prodigy 90 points


Say that you have three tasks, Lo, Mid and Hi, names corresponding to their respective OS priorities.
Lo takes a semaphore S1, which is priority inheritance-enabled, and which also happens to be free. Lo continues operation with its original priority.
Then Lo takes a semaphore S2, which also is priority inheritance, and also free. Lo continues operation with its original priority.
Then Mid preempts Lo and tries to take S1. Lo now gets elevated in priority to Mid's level.
Then Hi preempts Lo and tries to take S2. Lo now gets priority elevated to Hi's level.
Then Lo releases S2. Question: Is Lo's priority now lowered back to Mid's level?
Hi gets S2, does its job and releases S2. Lo now continues its work.
Then Lo releases S1. Question: Is Lo's priority now lowered back to Lo's original level?
I ask, because certain other real-time OS's will not lower Lo's priority back to Mid's level when S2 is released, but rather, will maintain the highest priority acquired through priority inheritance until the _last_ semaphore that is priority inheritance-enabled is released. In this exampel scenario, this means that Lo will run with S1 locked with Hi's priority, until S1 is released, at which time it gets Lo's original priority back. But in that mean time (i.e. after releasing S2, but before releasing S1), Lo will run with an incorrectly high priority.

  • 0
    TI__Prodigy 310 points

    Hi,

    Yes, you are correct; with priority inheritance, when Lo releases S2, Lo's priority should be lowered to Mid's(S1) priority and Hi should take S2 and finish its task.

    Lo should then run until it releases S1, of which then Lo's priority should be lowered to its original priority; This means that Mid would be able to take and release S1 as well as finish its task before Lo regains control and runs to completion.

    -Kevin

  • 0
    TI__Prodigy 310 points

    Also to clarify:

    TI RTOS does not support priority inheritance. We have semaphores that use priority, but those are used for ordering pending tasks and not inheritance.

    -Kevin

  • 0 in reply to Kevin Mao
    Prodigy 90 points

    Hi Kevin! Thanks for the swift reply, appreciate it.

    The wording "should be lowered" makes me nervous.
    Some more questions regarding this:

    1. Do you know for a fact that this is how SMP/BIOS works?
    2. Is there a test suite for SMP/BIOS that validates it?
    3. If so, is there a test for this precise scenario in that test suite?

    Again, I must ask since we've had terrible problems with other RTOS's.
    Our design have a direct dependency on this behaviour, which is why it is so crucial.

    Best regards,
    Lasse

  • 0 in reply to Kevin Mao
    Prodigy 90 points

    I don't understand those statements. :-)

    Are you saying that tasks do not get their priorities adjusted dynamically by SMP/BIOS, according to which tasks take the semaphores?
    If you only sort the list of pending tasks, and don't adjust the priority of a running task that owns a semaphore, then you don't have support for priority inheritance, as I see it.

    The very definition of priority inheritance for me is that the OS adjusts the priority dynamically.
    Do you have some other definition?
    What do you understand with priority inheritance?
    In your view, which RTOS has support for priority inheritance?

    Please elaborate!

    Best regards,
    Lasse

  • 0 in reply to user6284023
    TI__Prodigy 310 points

    As you said, priority inheritance involves the OS reassigning task priority dynamically based on semaphores. I did not mean to imply that TI-RTOS supports priority inheritance.

    The RTOS used by ti (TI-RTOS) does not support priority inheritance.

    sorry for any misunderstanding.

    -Kevin

  • 0 in reply to Kevin Mao
    TI__Guru* 96960 points

    Lasse,

    TI-RTOS does have the GateMutexPri module. This module can be used for mutual exclusion and it raises/lowers task priorities as need to prevent priority inversion. As Kevin stated, the Semaphore module itself does not supply this capability....only the GateMutexPri module.

    Todd

  • 0 in reply to ToddMullanix
    Prodigy 90 points

    Thanks, Todd!

    So, with the addition of the GateMutexPri to the TI RTOS build, we end up with an RTOS that _does_ support priority inheritance, as I understand it.
    I'm still a bit confused as to why you regard TI RTOS to not support priority inheritance.

    For the RTOS user, it is of no matter how that support is brought about.
    The important thing is that you get the desired semantics and avoid priority inversion.
    As I understand you, this is actually the case, when that particular module is included and used.

    So: Why don't you state that the TI RTOS supports priority inheritance then? :-)

    Best regards,
    Lasse

  • 0 in reply to user6284023
    TI__Guru* 96960 points

    I think the confusion on this thread came from asking if semaphores supported priority inheritance (which the Semaphore module does not). Only the GateMutexPri module does. 

    Todd

  • 0 in reply to ToddMullanix
    Prodigy 90 points

    OK, fair enough.

    My conclusion is that yes, TI-RTOS has support for priority inheritance, by using that GateMutexPri module.

    Thanks everyone involved!

    Best regards,
    Lasse