Task Pending on Semaphore - VxWorks

This is a discussion on Task Pending on Semaphore - VxWorks ; I have an interesting problem. I have a task A at priority 170. My code has a bunch of other tasks at several other priorities, both above and below 170. There are a few tasks running at priority 120. Occasionally ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Task Pending on Semaphore

  1. Task Pending on Semaphore

    I have an interesting problem. I have a task A at priority 170. My
    code has a bunch of other tasks at several other priorities, both
    above and below 170. There are a few tasks running at priority 120.
    Occasionally task A will increase its priority to 170. This looks
    like to be a task priority inversion problem. How do I determine what
    semaphore its pending on and who else owns it?

    Thanks in advance,
    -Daniel


  2. Re: Task Pending on Semaphore

    I made a typo in last message, I meant to say that task A increases
    its priority to 120, not 170.

    I have an interesting problem. I have a task A at priority 170. My
    code has a bunch of other tasks at several other priorities, both
    above and below 170. There are a few tasks running at priority 120.
    Occasionally task A will increase its priority to 120. This looks
    like to be a task priority inversion problem. How do I determine what
    semaphore its pending on and who else owns it?



    On Oct 24, 5:15 pm, Daniel wrote:
    > I have an interesting problem. I have a task A at priority 170. My
    > code has a bunch of other tasks at several other priorities, both
    > above and below 170. There are a few tasks running at priority 120.
    > Occasionally task A will increase its priority to 170. This looks
    > like to be a task priority inversion problem. How do I determine what
    > semaphore its pending on and who else owns it?
    >
    > Thanks in advance,
    > -Daniel




  3. Re: Task Pending on Semaphore

    On Oct 24, 8:15 pm, Daniel wrote:
    > I have an interesting problem. I have a task A at priority 170. My
    > code has a bunch of other tasks at several other priorities, both
    > above and below 170. There are a few tasks running at priority 120.
    > Occasionally task A will increase its priority to 170. This looks
    > like to be a task priority inversion problem. How do I determine what
    > semaphore its pending on and who else owns it?
    >
    > Thanks in advance,
    > -Daniel


    How this is done will depend upon the version of VxWorks you are
    using. I don't think that there is a show command that will do this
    for you. So, to do this yourself, you will need to inspect the task
    control block (TCB). I am assuming that you are either using VxWorks
    5.x or running in the kernel for 6.x. This is easy to get in the
    aforementionned cases. Your taskId returned by taskSpawn(),
    taskCreate(), or even taskIdSelf() is a pointer to the WIND_TCB ...
    the Wind River task control block. Reference the file target/h/
    taskLib.h for the exact field names that I am referring to next.

    There is a field called something like pPendQ. If this is not NULL,
    this identifies the queue that the task is pended upon. If memory
    serves, this pend queue typically belongs to either a semaphore or a
    message queue. The pend queues are at fixed offsets within a
    semaphore structure and message queue structure. So, you can take
    your pPendQ pointer, subtract the offset and test the resulting
    pointer against the semaphore type and message queue type. If either
    one passes, you have your object. In VxWorks (non-RTP cases) the
    object ID is really a pointer to the object.

    Now, if the object is pended upon an inversion safe mutex semaphore,
    the semaphore ID (or pointer to the semaphore) is saved in the TCB's
    pPriMutex field. In 6.x versions, if I remember correctly, this field
    is embedded in the priority inheritance data structure (which was
    added when the priority inheritance algorithm was improved). So, in
    that case, if you want to determine what task "owns" the mutex on
    which a task is blocking it is ...
    pBlockedTcb->pPriMutex->semOwner for 5.x
    pBlockedTcb->pPriData->pPriMutex->semOwner for 6.x

    Hope this helps.

    Peter


  4. Re: Task Pending on Semaphore

    On Oct 25, 5:41 am, peter.mit...@gmail.com wrote:
    > On Oct 24, 8:15 pm, Daniel wrote:
    >
    > > I have an interesting problem. I have a task A at priority 170. My
    > > code has a bunch of other tasks at several other priorities, both
    > > above and below 170. There are a few tasks running at priority 120.
    > > Occasionally task A will increase its priority to 170. This looks
    > > like to be a task priority inversion problem. How do I determine what
    > > semaphore its pending on and who else owns it?

    >
    > > Thanks in advance,
    > > -Daniel

    >
    > How this is done will depend upon the version of VxWorks you are
    > using. I don't think that there is a show command that will do this
    > for you. So, to do this yourself, you will need to inspect the task
    > control block (TCB). I am assuming that you are either using VxWorks
    > 5.x or running in the kernel for 6.x. This is easy to get in the
    > aforementionned cases. Your taskId returned by taskSpawn(),
    > taskCreate(), or even taskIdSelf() is a pointer to the WIND_TCB ...
    > the Wind River task control block. Reference the file target/h/
    > taskLib.h for the exact field names that I am referring to next.
    >
    > There is a field called something like pPendQ. If this is not NULL,
    > this identifies the queue that the task is pended upon. If memory
    > serves, this pend queue typically belongs to either a semaphore or a
    > message queue. The pend queues are at fixed offsets within a
    > semaphore structure and message queue structure. So, you can take
    > your pPendQ pointer, subtract the offset and test the resulting
    > pointer against the semaphore type and message queue type. If either
    > one passes, you have your object. In VxWorks (non-RTP cases) the
    > object ID is really a pointer to the object.
    >
    > Now, if the object is pended upon an inversion safe mutex semaphore,
    > the semaphore ID (or pointer to the semaphore) is saved in the TCB's
    > pPriMutex field. In 6.x versions, if I remember correctly, this field
    > is embedded in the priority inheritance data structure (which was
    > added when the priority inheritance algorithm was improved). So, in
    > that case, if you want to determine what task "owns" the mutex on
    > which a task is blocking it is ...
    > pBlockedTcb->pPriMutex->semOwner for 5.x
    > pBlockedTcb->pPriData->pPriMutex->semOwner for 6.x
    >
    > Hope this helps.
    >
    > Peter


    Hi,
    Other then the way mentioned by peter,you can optionally use windview
    tool supplied by windriver for 5.x versions to see graphically over
    the time period when your task A changes priority,observe what all
    tasks are pending and what semaphores are in use.This would need
    access to host machine like windows.However I believe you can do
    programatticaly what windview does using windview libs though I am not
    pretty sure.

    Hope this helps,
    Regards,
    s.subbarayan


  5. Re: Task Pending on Semaphore

    >> How do I determine what semaphore its pending on and who else owns it?
    >


    WRS Tech Tips 517:
    Problem Description
    Given a task ID, can you show what semaphore's that task either has or
    is
    blocked on?
    Problem Solution
    All of the sem* routines running on the target for showing and
    querying
    semaphore info require the sem ID of the semaphore you want to
    investigate.

    There is no way in VxWorks of showing semaphones held by a task.
    VxWorks
    does not keep track of semIDs, nor keep any list of semaphors
    anywhere. It
    is the job of the applications which use the semaphors to keep track
    of
    them.

    However, hostside tools do provide this functionality. It may
    sometimes be
    possible to find the ID of the single semaphor that some task is
    currently
    blocked on. To do this, you can use the TCL function taskWaitShow() to
    identify the object a task is pended on. This is described in the
    Tornado 2.0
    User's Guide, page 166 for both Unix and Windows versions of the
    manual.

    Since this is a TCL script, it can not be run on the target, but must
    be run
    from the host. The sources to taskWaitShow() are available in
    $(WIND_BASE)/host/resource/tcl. The following is a sample of the usage
    of
    taskWaitShow().

    -> i
    NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY
    ---------- ------------ -------- --- ---------- -------- --------
    ------- -----
    tExcTask _excTask 1fdc22c 0 PEND 61ada 1fdc188 0 0

    -> i
    NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY
    ---------- ------------ -------- --- ---------- -------- --------
    ------- -----
    tExcTask _excTask 1fdc22c 0 PEND 61ada 1fdc188 0 0
    tLogTask _logTask 1fd9904 0 PEND 61ada 1fd985c 0 0
    tShell _shell 1f019b8 1 PEND 29ece 1f01658 0 0
    tTelnetd _telnetd 1f05278 2 PEND 29ece 1f0518c 0 0
    tWdbTask 0x1e184 1f02b80 3 READY 29ece 1f02ad4 0 0
    tNetTask _netTask 1f328a4 50 READY 29e2e 1f3277c 0 0
    value = 0 = 0x0

    -> taskWaitShow 0x1f328a4
    NAME ENTRY TID
    STATUS DELAY OBJ_TYPE OBJ_ID OBJ_NAME
    ---------- ---------- -------- ---------- ----- ---------- --------
    ------------
    tNetTask _netTask 1f328a4 READY 0 0
    value = 0 = 0x0

    -> taskWaitShow 0x1fd9904
    NAME ENTRY TID
    STATUS DELAY OBJ_TYPE OBJ_ID OBJ_NAME
    ---------- ---------- -------- ---------- ----- ---------- --------
    ------------
    tLogTask _logTask 1fd9904 PEND 0 MSG_Q(R) 1fd9abc N/A
    value = 0 = 0x0

    -> taskWaitShow tExcTask
    NAME ENTRY TID
    STATUS DELAY OBJ_TYPE OBJ_ID OBJ_NAME
    ---------- ---------- -------- ---------- ----- ---------- --------
    ------------
    tExcTask _excTask 1fdc22c PEND 0 MSG_Q(R) 1fdc3e4 N/A
    value = 0 = 0x0

    ->
    If one of the tasks shown by taskWaitShow() is waiting on a semaphore,
    then
    the semId will show up in the OBJ_ID field. This semId can be used
    with the
    vxWorks sem* commands such as semShow(), on either the host or target
    shells.



+ Reply to Thread