Re: Task Pending on Semaphore
- From: peter.mitsis@xxxxxxxxx
- Date: Wed, 24 Oct 2007 17:41:40 -0700
On Oct 24, 8:15 pm, Daniel <dantheman0...@xxxxxxxxx> 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
.
- Follow-Ups:
- Re: Task Pending on Semaphore
- From: ssubbarayan
- Re: Task Pending on Semaphore
- References:
- Task Pending on Semaphore
- From: Daniel
- Task Pending on Semaphore
- Prev by Date: Re: Task Pending on Semaphore
- Next by Date: Re: Problem connecting to VxWorks Target Agent
- Previous by thread: Re: Task Pending on Semaphore
- Next by thread: Re: Task Pending on Semaphore
- Index(es):
Relevant Pages
|