• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 509 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.

[Sys/Bios] How Does One Determine What a Task is Pending On?

Alex
Expert 2430 points

Say you have a standard while(1){...} task implementation that's pending on some event object to wake it up.  Now, inside that task, you need to pend on something else (e.g., data from another core, task, or whatever).  From another task, how does one determine at runtime which of those two event objects the task is currently blocked on?

I know it's doable because ROV (in CCS) can determine the information, but I can't find any reference to this type of query in the documentation.

  • 0
    TI__Mastermind 26780 points

    Alex,

    There are no runtime APIs that the application can query to determine what other Tasks are blocked upon.  

    ROV can present this information because it has knowledge of internal kernel data structures, and can scan and traverse these to determine kernel and thread states.

    If you are using events, one option might be to use the Event_getPostedEvents() API to see which eventsIds are still pending.  If you know that other Task is pending on these eventIds, then you know what it is still waiting on.

    Scott

  • 0 in reply to ScottG
    Expert 2430 points

    Ah, well, you see, therein lies the problem.  These inner events are only waiting on one trigger.  A semaphore would suffice, but I want the ability to use an Abort event (via the AND mask).

    I can't blindly post an Abort trigger to this event because if the task is not currently pending on it, the Abort won't kick in until it is, and then it would a bad thing.

    Anyway, I guess I can just maintain my own state information.  Not a bad plan, of course, but we are at the end of the project, so as you can imagine, that means a lot of code updates as our system is fairly large.

    Thanks, though, for information!  Glad to know I wasn't just missing the obvious.