Re: Task goes into a Pend+I state : Semaphore issue?
- From: "krishna" <kaushal.r@xxxxxxxxx>
- Date: 13 Mar 2006 00:46:15 -0800
Hi kapslock,
This seems to be a standard producer consumer
problem.The common resource to be protected is the queue of commands.
This is the problem of synchrnonization and not mutual exclusion.Hence
opt for binary semaphore.This should fix the inheritance problem.
This can be solved not with one but with two semaphores.That would be
the perfect solution independent of scheduling policy and
priorities.Soln
Go for two semaphores: SA governed by task A,initial value =1
SB governed by task B,initial value
=0
Inside the code for task A:
semTake(SA)
put the cmd in the queue.
semGive(SB)
Inside the code for task B:
semTake(SB)
put the cmd in the queue.
semGive(SA)
This would give the perfect solution avoiding all kind of race
conditions.
The issue in previous case 'could be' because of same semaphore ID
used by some other task of priority 20 or temp. raising to priority 20.
When you changed the priorities of the tasks you could get 'some
progress'.Hence it must be the issue with priorities.This should get
resolved when you opt for binary semaphore.Make sure the semaphore IDs
are UNIQUE in the system.
Hope this was useful.
cheers-
kaushal.
.
- References:
- Task goes into a Pend+I state : Semaphore issue?
- From: kapslocked@xxxxxxxxx
- Re: Task goes into a Pend+I state : Semaphore issue?
- From: Graham Baxter
- Task goes into a Pend+I state : Semaphore issue?
- Prev by Date: Re: sysAuxClkRateSet, etc.
- Next by Date: windml 2.0
- Previous by thread: Re: Task goes into a Pend+I state : Semaphore issue?
- Next by thread: Re: Task goes into a Pend+I state : Semaphore issue?
- Index(es):
Relevant Pages
|