Regarding priority ceiling
Prafulla Harpanhalli
I am using a mutex semaphore created with (SEM_INVERSION_SAFE |
SEM_Q_PRIORITY) option. So, the task that manages to lock this
semaphore successfully executes with the highest priority.
Can anybody please tell me what is the priority ceiling limit in
VxWorks? I know that an application with such a design is not a good
one, but still i wanted to know the limit. Has anybody come across a
situation like this?
And basically, what points people at WRS might have taken into
consideration in fixing such a limit?
TIA
-Prafulla Harpanhalli
Michael Lawnick
read the manual carefully again, you got something wrong!
> I am using a mutex semaphore created with (SEM_INVERSION_SAFE |
> SEM_Q_PRIORITY) option. So, the task that manages to lock this
> semaphore successfully executes with the highest priority.
SEM_INVERSION_SAFE : If a task has taken this sema and is preempted later
on, its priority will be increased to the level the premempting task has if
it is trying to take the same sema.
I.e. priority will only change if there dynamically arises a conflict on the
same inversion save semaphore.
SEM_Q_PRIORITY: Multiple tasks trying to get the semaphore while its already
taken will not be queued by request order but sorted by their priority. So
the task with highest priority pending on this particular semaphore will get
it when the holding task gives it back.
> Can anybody please tell me what is the priority ceiling limit in
> VxWorks?
0
> And basically, what points people at WRS might have taken into
> consideration in fixing such a limit?
Priority has a range 0<=x<=255, I assume historical it was in char variable.
To change priority of a particular task use taskPrioritySet().
Again: Re-read the manuals.
HTH
--
Regards,
Michael
21 is only half the truth.
FAQ - "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
Wiki -
"http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Books/VxWorksCookBook"
"Prafulla Harpanhalli" <prafu...@rediffmail.com> schrieb im Newsbeitrag
news:2797a21d.04030...@posting.google.com...
Prafulla Harpanhalli
> Hi Prafulla,
>
> read the manual carefully again, you got something wrong!
>
> > I am using a mutex semaphore created with (SEM_INVERSION_SAFE |
> > SEM_Q_PRIORITY) option. So, the task that manages to lock this
> > semaphore successfully executes with the highest priority.
> SEM_INVERSION_SAFE : If a task has taken this sema and is preempted later
> on, its priority will be increased to the level the premempting task has if
> it is trying to take the same sema.
> I.e. priority will only change if there dynamically arises a conflict on the
> same inversion save semaphore.
> SEM_Q_PRIORITY: Multiple tasks trying to get the semaphore while its already
> taken will not be queued by request order but sorted by their priority. So
> the task with highest priority pending on this particular semaphore will get
> it when the holding task gives it back.
Thanx for the explanation, but i am afraid, that did'nt answer my
question.
> > Can anybody please tell me what is the priority ceiling limit in
> > VxWorks?
> 0
> > And basically, what points people at WRS might have taken into
> > consideration in fixing such a limit?
> Priority has a range 0<=x<=255, I assume historical it was in char variable.
>
> To change priority of a particular task use taskPrioritySet().
Beats me. Do you mean say that my task will have its prority increased
atmost 254 times assuming my task started with an initial proirity of
255 (lowest) untill priority reaches 0(highest)? In that case, prority
ceiling limit is 254 in worst case.
> Again: Re-read the manuals.
I doubt if nanuals talk about ceiling.
> HTH
> --
>
> Regards,
> Michael
Thanx for your time.
WBR
-Prafulla
Michael Lawnick
> > > VxWorks?
> > 0
> > > And basically, what points people at WRS might have taken into
> > > consideration in fixing such a limit?
> > Priority has a range 0<=x<=255, I assume historical it was in char
variable.
> >
> > To change priority of a particular task use taskPrioritySet().
>
> Beats me. Do you mean say that my task will have its prority increased
> atmost 254 times assuming my task started with an initial proirity of
> 255 (lowest) untill priority reaches 0(highest)? In that case, prority
> ceiling limit is 254 in worst case.
have a standard priority which may be increased.
That is not VxWorks. There is no incrementation of a priority, just a
value:
May taskA have prio 100 and have taken inversion-save semX. It is doing some
longer calculation.
Now it may be preempted by taskB that runs at prio 80. When B runs onto
semTake(semX) it is preempted and taskA inherits the priority of taskB, i.e.
taskA now continues with prio 80 until all inversion save semaphores taken
by A are given back. It then is set back to 100 and will be preempted by B
again.
This leads to a minimum wait time of taskB on its semTake(semX).
HTH
--
Regards,
Michael
21 is only half the truth.
FAQ - "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
Wiki -
"http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Books/VxWorksCookBook"
"Prafulla Harpanhalli" <prafu...@rediffmail.com> schrieb im Newsbeitrag
news:2797a21d.04030...@posting.google.com...
Prafulla Harpanhalli
> > atmost 254 times assuming my task started with an initial proirity of
> > 255 (lowest) untill priority reaches 0(highest)? In that case, prority
> > ceiling limit is 254 in worst case.
> If I understand you correctly, you see all from UNIX or Win32, where you
> have a standard priority which may be increased.
> That is not VxWorks. There is no incrementation of a priority, just a
> value:
> May taskA have prio 100 and have taken inversion-save semX. It is doing some
> longer calculation.
> Now it may be preempted by taskB that runs at prio 80. When B runs onto
> semTake(semX) it is preempted and taskA inherits the priority of taskB, i.e.
> taskA now continues with prio 80 until all inversion save semaphores taken
> by A are given back. It then is set back to 100 and will be preempted by B
> again.
> This leads to a minimum wait time of taskB on its semTake(semX).
I perfectly agree with you. But there might be a scenario where other
/higher priority tasks/ will try to lock this semX. And as you said,
taskA /keeps on/ inheriting the proirity of such tasks.
My question: how long will taskA keep on inheriting priorities of
other tasks, assuming it still has some work to be done? Till the
priority of taskA reaches 0 or is there any limit set in Wind kernel?
Thanx for your patience.
-Prafulla
Michael Lawnick
to take the semaphore.
As 0 is the maximum priority, here is the end.
Its a very simple but(/therefore ;-)) effectiv mechanism.
biju k
> to take the semaphore.
> As 0 is the maximum priority, here is the end.
> Its a very simple but(/therefore ;-)) effectiv mechanism.
Does that means that kernel will be preempted by task A as the kernel
runs at zero priority.Then isnt it the whole thing priority
inheritance.
I am confused..
Can someone expalin me what exactly is the difference between priority
ceiling and priority inheritance?
Thanks and regards,
Biju Koruthu.
subbarayan
The case u have discussed has the following reason:
Generally when mutex semaphore is in the scenerio the task aquiring
the semaphore will be boosted to the highest level of priority(highest
level here means,given a group of tasks pending for same semaphore at
the same point of time or requesting same semaphore,the task which
aquires the semaphore will be boosted to highest level of priority
which is equal to the priority of the highest priority task waiting to
take semaphore.This makes sense as this prevents,priority inversion
and also semaphore deletion).
Hope this makes u understand and answers ur query.
Regards,
s.subbarayan
"Michael Lawnick" <michael.lawnick@no_spam_pls.kontron.com> wrote in message news:<404f3...@news.arcor-ip.de>...
Prafulla Harpanhalli
> Dear prafulla,
> The case u have discussed has the following reason:
> Generally when mutex semaphore is in the scenerio the task aquiring
> the semaphore will be boosted to the highest level of priority(highest
> level here means,given a group of tasks pending for same semaphore at
> the same point of time or requesting same semaphore,the task which
> aquires the semaphore will be boosted to highest level of priority
> which is equal to the priority of the highest priority task waiting to
> take semaphore.
My question was: how long will this
increase_my_priority_to_that_of_high_priority_task will continue?
Once, twice, n times? What is this 'n'? AFAIK, this 'n' signifies PC
limit.
>This makes sense as this prevents,priority inversion
> and also semaphore deletion).
> Hope this makes u understand and answers ur query.
> Regards,
> s.subbarayan
Many thanx to Michael and you.
-Prafulla
Claudio Potenza
> > The answer is given above: taskA inherites the priority of the task trying
> > to take the semaphore.
> > As 0 is the maximum priority, here is the end.
> > Its a very simple but(/therefore ;-)) effectiv mechanism.
>
>
> Does that means that kernel will be preempted by task A as the kernel
> runs at zero priority.Then isnt it the whole thing priority
> inheritance.
In vxWorks (at least 5.x) there is no "kernel" like in Unix. When a
task executes a "system call" it is really simply calling a function
likek any other and so it normally retains its priority all the time.
Jerald Pendleton
This is very true and is one of the things that is hard to (at first)
understand in vxWorks.
There are cases where a task will enable a higher priority task. The
most obvious is the tNetTask which handles the networking. This usually
runs around 50, so if something comes in from the network that needs to be
processed, the lower priority tasks are preempted. You can of course
avoid this, by making you task 49 or so, but in IMHO you better have
a *damn* good reason to that.
Less obvious cases are tExcTask which handles among other thing logMsg
and my old dear friend the target shell which runs at 1. There is also
some stuff that runs at each tick of the system clock.
Windview is very good a visualizing this stuff - particularly
priority inheritance. It's not always obvious.
> _______________________________________________
> VxWorks Users Group mailing list
> VxWe...@lbl.gov
> http://www-csg.lbl.gov/vxworks/
--
Jerald Pendleton
Via the HackVan
jer...@fangdog.com
www.fangdog.com
ICBM: 37d 42' 32.062 N Lat
122d 4' 31.750 W Lon
Castro Valley, California
joe durusau
Prafulla Harpanhalli wrote:
> ssu...@blr.pin.philips.com (subbarayan) wrote in message news:<635cdb91.04031...@posting.google.com>...
> > Dear prafulla,
> > The case u have discussed has the following reason:
> > Generally when mutex semaphore is in the scenerio the task aquiring
> > the semaphore will be boosted to the highest level of priority(highest
> > level here means,given a group of tasks pending for same semaphore at
> > the same point of time or requesting same semaphore,the task which
> > aquires the semaphore will be boosted to highest level of priority
> > which is equal to the priority of the highest priority task waiting to
> > take semaphore.
>
> My question was: how long will this
> increase_my_priority_to_that_of_high_priority_task will continue?
> Once, twice, n times? What is this 'n'? AFAIK, this 'n' signifies PC
> limit.
Soemhow, the 'n' has gotton lost in the fog. I don't see it in the
preceeding. The idea is :
Suppose task A, pri 200, takes two MUTEX.sems, X and Y.
Suppose task B, pri 50, tries to take MUTEX X, and blocks.
Now: task A is promoted to pri 50 and stays there until it
releases both X and Y. It then returns to pri 200. This feature
is what is called priority inheritance. In 5.4 and earlier, I cannot
find any reference to priority ceiling. What version are you running.
I can guess as to what it means, but would rather not.
>
>
> >This makes sense as this prevents,priority inversion
> > and also semaphore deletion).
> > Hope this makes u understand and answers ur query.
> > Regards,
> > s.subbarayan
>
> Many thanx to Michael and you.
> -Prafulla
Speaking only fro myself,
Joe Durusau
subbarayan
the time to which the task will be promoted to highest level will be
equal to the time till which u decide u don't require the semaphore
any more.i.e,till u hold the semaphore u will be the highest priority
.
Hope its clear now.
Regards,
s.subbarayan
prafu...@rediffmail.com (Prafulla Harpanhalli) wrote in message news:<2797a21d.04031...@posting.google.com>...
Martin Raabe
as far as I know, there is not a ceiling limit as to be found in pSOSystem
Mutexes.
Hope it helps.
Take care
--
BaSystem Martin Raabe
E: Martin.Raabe<at>B-a-S-y-s-t-e-m<dot>de
"joe durusau" <joe.d...@lmco.com> schrieb im Newsbeitrag
news:405092C4...@lmco.com...