Some questions on QNX

[Bill_Caroselli_Q-TPS]

If a resource manager needs to handle both hardware interrupts and client
requests, it should be multi-threaded. That’s what threads are there for.

The thread that handles the hardware interrupts can be locked into a high
priority while the thread(s) that handle client requests can be allowed to
float.

“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:asnvq1$2ik$1@inn.qnx.com…

Xiaodan Tang wrote:
Armin Steinhoff <> a-steinhoff@web.de> > wrote in message
news:asnath$98t$> 1@inn.qnx.com> …

I have a felling that you have no clue what is a “priority inversion”
and
why/how floating priorities is important.

Sorry … you have simply a wrong feeling >

I said:
If a resource manager has to handle critical time contrains at
hardware level it wouldn’t be a good idea to run it with a floating
priority.

… end this is mostly the case when we deal with resource managers of
the (core) system.

[David_Gibbs1]

Armin Steinhoff <a-steinhoff@web.de> wrote:

Xiaodan Tang wrote:
It exist as a flag (that the resource manager
programmer could control) for a reason.

Is there a documentation of the process flags? (QNX4 has it …)

It isn’t a process flag, it is a channel flag. Check ChannelCreate()
_NTO_CHF_FIXED_PRIORITY is the flag.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Armin_Steinhoff1]

David Gibbs wrote:

Armin Steinhoff <> a-steinhoff@web.de> > wrote:

David Gibbs wrote:

Armin Steinhoff <> a-steinhoff@web.de> > wrote:



A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )


Why?
They float to the priority of the thread that sent to them, or who’s
request they are servicing.


OK … I tried to check it out, but the print out of process flags
returned by pidin aren’t documented.


It isn’t a process flag, as in QNX4, it is a channel flag.

OK … I mean ‘pidin fl’ → it returns also the process flags.
(may be there is a break in the terminology …)

Check docs for ChannelCreate() and _NTO_CHF_PRIORITY_FIXED is, I think,
the flag to disable this behaviour.

So if _NTO_CHF_PRIORITY_FIXED is used … is it listed in the so called
‘process flags’ returned by ‘pidin fl’ ??

So, if you run something READY at priority 30, then someone at priority
32 makes a request, the proc thread that services that request will run
at priority 32, and you won’t be pre-empted.


OK … this works only if the other process talks to the same service
task or thread. But with a multi threaded resource manager your task
( that means your active resource manager thread) will be pre-empted.


Whatever thread in the resource manager is chosen to “receive” that
request will run at the priority of the requesting process.

If you make all your real-time important task run above priority 30,
then they, and all servers they make requests to, will run at that
priority to service the request.

Ok … that the case if we have channels with floating priorities …

Note: most embedded and realtime systems do not have an environment
where people can compile or run arbitrary programs.

Not arbitrary programms … but which program is running when is event
driven and therefor arbitrary.

If a resource manager has to handle critical time contrains at hardware
level it wouldn’t be a good idea to run it with a floating priority.


Depends on how you structure things… usually hardware constraints mean
you’re dealing with interrupts.

Yes … at least.

Two main choices here:

– hw thread uses InterruptWait(), runs at high priority, doesn’t receive
messages, so never floats in priority
– isr/event delivered is a pulse, with a high priority (pulses also carry
priority information) then the thread receiving the hardware pulse will
float to the (high) priority specified in the pulse

What happens if the message handler of the main thread of a resource
manager isn’t able to send received data to the hardware interface
because of the low priority of the requestor? Who will be blamed for
the malfunction? The resource manager? The hardware? (Floppy …)

IMHO, what we also need are design rules for user level processes in
order to make sure that these processes can’t pe-empt interrupt threads.
(layered priority schemes …)

Armin

So just a big question mark behind that usage of floating priorities in
that context …


– can be (and often is) avoided in that situation

-David

[Armin_Steinhoff1]

Bill Caroselli (Q-TPS) wrote:

If a resource manager needs to handle both hardware interrupts and client
requests, it should be multi-threaded. That’s what threads are there for.

The thread that handles the hardware interrupts can be locked into a high
priority while the thread(s) that handle client requests can be allowed to
float.

… and the last point is the weak point

“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:asnvq1$2ik$> 1@inn.qnx.com> …

Xiaodan Tang wrote:

Armin Steinhoff <> a-steinhoff@web.de> > wrote in message
news:asnath$98t$> 1@inn.qnx.com> …

I have a felling that you have no clue what is a “priority inversion”

and

why/how floating priorities is important.

Sorry … you have simply a wrong feeling >

I said:
If a resource manager has to handle critical time contrains at
hardware level it wouldn’t be a good idea to run it with a floating
priority.

… end this is mostly the case when we deal with resource managers of
the (core) system.

\

[David_Gibbs1]

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

If a resource manager needs to handle both hardware interrupts and client
requests, it should be multi-threaded. That’s what threads are there for.

I wouldn’t go so far as “should be”, but would say “could be”.

It depends.

How long/short is the handling of any particular client interaction?
How short does the latency of the interrupt handling have to be?

Going multi-threaded introduces a number of other complexities –
all those nasty synchronisation issues.

devc-ser8250 is a resource manager that handles hardware interrupts
and client requests, and it is not multi-threaded.

The thread that handles the hardware interrupts can be locked into a high
priority while the thread(s) that handle client requests can be allowed to
float.

Yup. Though, personally, I like the high-priority pulse handled by a
single-thread blocked on MsgReceive(), with it floating high to handle
the interrupt pulse, and lower for client threads. (If, of course,
you can get away with that design.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[David_Gibbs1]

Armin Steinhoff <a-steinhoff@web.de> wrote:

David Gibbs wrote:

It isn’t a process flag, as in QNX4, it is a channel flag.

OK … I mean ‘pidin fl’ → it returns also the process flags.
(may be there is a break in the terminology …)

It isn’t a process flag.

A process can have 2 channels. One channel has the default, one
has set _NTO_CHF_FLAG_FIXED_PRIORITY. 3 threads blocked on the
first channel will float, 2 threads blocked on the 2nd channel
will not float. What could a process flag say for something like
that?

It isn’t a process level setting, so it can’t be reflected in
a process level flag.

You do have a point, though, that the docs to pidin don’t describe
the meaning of the flags output. I expect there are a number
of output modes for pidin that are not completely documented, and
probably should be.

Check docs for ChannelCreate() and _NTO_CHF_PRIORITY_FIXED is, I think,
the flag to disable this behaviour.

So if _NTO_CHF_PRIORITY_FIXED is used … is it listed in the so called
‘process flags’ returned by ‘pidin fl’ ??

No. It isn’t. It isn’t a PROCESS flag, it is a channel flag.

Note: most embedded and realtime systems do not have an environment
where people can compile or run arbitrary programs.

Not arbitrary programms … but which program is running when is event
driven and therefor arbitrary.

Not entirely arbitrary, but yes it is a system design issue.

Two main choices here:
– hw thread uses InterruptWait(), runs at high priority, doesn’t receive
messages, so never floats in priority
– isr/event delivered is a pulse, with a high priority (pulses also carry
priority information) then the thread receiving the hardware pulse will
float to the (high) priority specified in the pulse

What happens if the message handler of the main thread of a resource
manager isn’t able to send received data to the hardware interface
because of the low priority of the requestor? Who will be blamed for
the malfunction? The resource manager? The hardware? (Floppy …)

The system designer.

Seriously. If you have designed your system such that somebody
supplying data for hardware – saying the next block you want to
write to a disk – and that person hasn’t gotten enough CPU to
send it to your resource manager, due to being pre-empted by other
things, then when you designed your system, and decided the priority
of things, you didn’t give it a high enough priority. Or, this
“failure” is not a failure, but a normal case… the hardware will
wait/the block won’t be written until the next block is available. Sure,
you might get a lag, lowered throughput to your hard drive due to not
having another block to DMA when you got the DMA completed irq, but
is this a failure of any of the pieces? Or just a normal state.

IMHO, what we also need are design rules for user level processes in
order to make sure that these processes can’t pe-empt interrupt threads.
(layered priority schemes …)

That sort of consideration is a good one to undertake when designing
a system, yes.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Warren_Deitch1]

How would a resource manager programmer get to set _NTO_CHF_FIXED_PRIORITY. It is buried deep inside resmgr_attach.


Previously, David Gibbs wrote in comp.os.qnx:

Armin Steinhoff <> a-steinhoff@web.de> > wrote:
Xiaodan Tang wrote:
It exist as a flag (that the resource manager
programmer could control) for a reason.

Is there a documentation of the process flags? (QNX4 has it …)

It isn’t a process flag, it is a channel flag. Check ChannelCreate()
_NTO_CHF_FIXED_PRIORITY is the flag.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[David_Gibbs1]

Warren Deitch <warren.deitch@transcore.com.au> wrote:

How would a resource manager programmer get to set
_NTO_CHF_FIXED_PRIORITY. It is buried deep inside resmgr_attach.

It is. I’m not sure a resource manager programmer can set it.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Xiaodan_Tang1]

One can ChannelCreate() a channel, and pass it to _dispatch_create(chid,
flag).

But yes, since _dispatch_create() is not documented, I guess this is not the
“offical” solution.

-xtang

David Gibbs <dagibbs@qnx.com> wrote in message
news:at2ig3$lid$1@nntp.qnx.com…

Warren Deitch <> warren.deitch@transcore.com.au> > wrote:
How would a resource manager programmer get to set
_NTO_CHF_FIXED_PRIORITY. It is buried deep inside resmgr_attach.

It is. I’m not sure a resource manager programmer can set it.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Rennie_Allen2]

Armin Steinhoff wrote:

Xiaodan Tang wrote:

Sorry … you have simply a wrong feeling >

Xiaodan is not the only one reading this thread with that
same feeling.

If a resource manager has to handle critical time contrains at
hardware level it wouldn’t be a good idea to run it with a floating
priority.

Uh, how exactly is it that floating priority is bad for a resource
manager that has critical time constraints (conventional wisdom is
exactly the opposite).

… end this is mostly the case when we deal with resource managers of
the (core) system.

Funny, I’ve written resource managers (on QNX4) using nothing
but priority float with hard deadlines, and I have found that
they work much worse, if I turn priority float off (worse, as
in “mars pathfinder” worse - i.e. they no longer meet their
deadlines, since low priority clients cause priority inversion).

[Armin_Steinhoff1]

Rennie Allen wrote:

Armin Steinhoff wrote:

Xiaodan Tang wrote:

Sorry … you have simply a wrong feeling >

Xiaodan is not the only one reading this thread with that
same feeling.

Ok … you and Xiaodan.

If a resource manager has to handle critical time contrains at
hardware level it wouldn’t be a good idea to run it with a
floating >> priority.


Uh, how exactly is it that floating priority is bad for a resource
manager that has critical time constraints (conventional wisdom is
exactly the opposite).

“conventional wisdom” or the common sense says also that there must be a
lower bound for the resource manager priority … so no simple user
application could push down the priority of an important resource
manager to a level where every simple user application could pre-empt
the resource manager.

… end this is mostly the case when we deal with resource managers of
the (core) system.


Funny, I’ve written resource managers (on QNX4) using nothing
but priority float with hard deadlines, and I have found that
they work much worse, if I turn priority float off

There are also resource managers of QNX4 from QSSL which doesn’t float
its priority. Use ‘sin’ and look to the process flags.

Armin

[Robert_Krten1]

Igor Kovalenko <kovalenko@attbi.com> wrote:

“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:at7774$9gh$> 1@inn.qnx.com> …
Rennie Allen wrote:
Armin Steinhoff wrote:

Xiaodan Tang wrote:

Sorry … you have simply a wrong feeling >

Xiaodan is not the only one reading this thread with that
same feeling.

Ok … you and Xiaodan.

If a resource manager has to handle critical time contrains at
hardware level it wouldn’t be a good idea to run it with a
floating >> priority.


Uh, how exactly is it that floating priority is bad for a resource
manager that has critical time constraints (conventional wisdom is
exactly the opposite).

“conventional wisdom” or the common sense says also that there must be a
lower bound for the resource manager priority … so no simple user
application could push down the priority of an important resource
manager to a level where every simple user application could pre-empt
the resource manager.

If the resmgr is multithreaded and only the thread serving a request from
low-priority client inherits the low priority then I don’t see anything
wrong with preempting that thread by another user application with ‘normal’
priority.

I think the reason QNX4 has resmgrs with no priority inheritance is because
QNX4 does not support threads, so they had to protect ‘vital’ resmgrs from
flood of low-priority clients. This does not apply to QNX6.

But but but … doesn’t the thread (or process in case of QNX 4) get bumped
to be the highest of the waiting clients?

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

[Igor_Kovalenko2]

“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:at7774$9gh$1@inn.qnx.com…

Rennie Allen wrote:
Armin Steinhoff wrote:

Xiaodan Tang wrote:

Sorry … you have simply a wrong feeling >

Xiaodan is not the only one reading this thread with that
same feeling.

Ok … you and Xiaodan.

If a resource manager has to handle critical time contrains at
hardware level it wouldn’t be a good idea to run it with a
floating >> priority.


Uh, how exactly is it that floating priority is bad for a resource
manager that has critical time constraints (conventional wisdom is
exactly the opposite).

“conventional wisdom” or the common sense says also that there must be a
lower bound for the resource manager priority … so no simple user
application could push down the priority of an important resource
manager to a level where every simple user application could pre-empt
the resource manager.

If the resmgr is multithreaded and only the thread serving a request from
low-priority client inherits the low priority then I don’t see anything
wrong with preempting that thread by another user application with ‘normal’
priority.

I think the reason QNX4 has resmgrs with no priority inheritance is because
QNX4 does not support threads, so they had to protect ‘vital’ resmgrs from
flood of low-priority clients. This does not apply to QNX6.

– igor

[Xiaodan_Tang1]

Robert Krten <nospam83@parse.com> wrote in message
news:at8593$cpl$1@inn.qnx.com…

Igor Kovalenko <> kovalenko@attbi.com> > wrote:
“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:at7774$9gh$> 1@inn.qnx.com> …

“conventional wisdom” or the common sense says also that there must be
a
lower bound for the resource manager priority … so no simple user
application could push down the priority of an important resource
manager to a level where every simple user application could pre-empt
the resource manager.

If the resmgr is multithreaded and only the thread serving a request
from
low-priority client inherits the low priority then I don’t see anything
wrong with preempting that thread by another user application with
‘normal’
priority.

I think the reason QNX4 has resmgrs with no priority inheritance is
because
QNX4 does not support threads, so they had to protect ‘vital’ resmgrs
from
flood of low-priority clients. This does not apply to QNX6.

But but but … doesn’t the thread (or process in case of QNX 4) get
bumped
to be the highest of the waiting clients?

Yes! Let me make it clear on the “floating priority” resource manager.

Let’s say there is a low priority (say 5) client and a high priority (say
15) access
the same resource manager.

if the resource manager is single threaded (as QNX4 process):

1. it drop to 5 to service it’s priority 5 client;

Once the priority 15 client MsgSend() to the manager, since there is no
one
waiting to receive the message, the resource manager priority will be
BUMPED UP
to 15 for the rest of it’s run (even though it is service a priority 5
client).

if the resource manager is multi threaded.

1. it drop to 5 to service the priority 5 client, once priority 15 reqeust
   comming in,
   priority 5 thread preempted, priority 15 thread run (to service the
   priority 15 client)
   when it is done (block on sth else, run out of its timeslice…) the
   priority 5 thread
   get resumed from where it preempted.

2. what if the priority 5 thread locked down a mutex because it is in a
   critical section?
   the priority 15 thread will run, as soon as the priority 15 thread try
   to lock the same
   mutex, it will be blocked, BUT, the prioirty 5 thread will be BUMPED UP
   to priority
   15, (because there is a high priority guy want the mutex hold by him) and
   run (still
   in service of priority 5 client).
   As soon this thread release the mutex, it will be “BUMPED DOWN” to it’s
   orignal
   priority (which is 5), and the priority 15 thread will get the mutex,
   and preempt it.

Now, what if the resource manager is service priority 5 client (so the
service thread is
priority 5), and in a “time critical hardware access”. And then a priority
20 client
just run (without talk to same resource manager).

The priority 20 client will preempt the priority 5 resource manager thread,
the “time
critical hardware access” may fail! But, the real question here is: “WHY
there is a
priority 20 client running” ? Is it really important enough tha the priority
5 client ?

If you still answer “YES” to this question, then you want to make sure your
resource manager that when it start the “time critical hardware access”,
they
bump themself up to make themself “important enough” so there is no one
(or only choosed “more important” client) could preempt them.

Hookup as an ISR, or using InterruptAttachEvent() to get a high priority
pulse
(so the resmgr thread will bumped high) are all usual practice.

So to me, the BIG QUESTION is why “NOT TO” use the floating priority
resource manager.

-xtang

[Xiaodan_Tang1]

Armin Steinhoff <a-steinhoff@web.de> wrote in message
news:at8ae7$ie8$1@inn.qnx.com…

Igor Kovalenko wrote:
“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:at7774$9gh$> 1@inn.qnx.com> …

“conventional wisdom” or the common sense says also that there must be a
lower bound for the resource manager priority … so no simple user
application could push down the priority of an important resource
manager to a level where every simple user application could pre-empt
the resource manager.


If the resmgr is multithreaded

Yes … IF ans only IF the resmgr is multithreaded. But show me a
resource manager with multiple message handler threads!

What does that mean ?! pipe, fs-pkg, devb-fdc, devb-eide, aren’t they
all “resource manager with multiple message handler threads” ?

and only the thread serving a request from
low-priority client inherits the low priority then I don’t see anything
wrong with preempting that thread by another user application with
‘normal’
priority.

Well … is’t then just a single client which doesn’t get an answer …
who cares >

I think the reason QNX4 has resmgrs with no priority inheritance is
because
QNX4 does not support threads, so they had to protect ‘vital’ resmgrs
from
flood of low-priority clients.
This does not apply to QNX6.

Why doesn’t this apply to QNX6?? Not every resmgr is or can be multi
threaded.

It should apply to QNX6. And floating priority just work fine to them. (see
my
other post on how floating priority handled on a single thread resource
manager).

-xtang

[Armin_Steinhoff1]

Xiaodan Tang wrote:
[ clip ]

QNX4 does not support threads, so they had to protect ‘vital’ resmgrs

from

flood of low-priority clients. This does not apply to QNX6.

But but but … doesn’t the thread (or process in case of QNX 4) get

bumped

to be the highest of the waiting clients?


Yes! Let me make it clear on the “floating priority” resource manager.

Let’s say there is a low priority (say 5) client and a high priority (say
15) access
the same resource manager.

if the resource manager is single threaded (as QNX4 process):

1. it drop to 5 to service it’s priority 5 client;

Once the priority 15 client MsgSend() to the manager, since there is no one
waiting to receive the message, the resource manager priority will be
BUMPED UP

or better boosted

to 15 for the rest of it’s run (even though it is service a priority 5

client).

if the resource manager is multi threaded.

1. it drop to 5 to service the priority 5 client, once priority 15 reqeust
   comming in,
   priority 5 thread preempted, priority 15 thread run (to service the
   priority 15 client)
   when it is done (block on sth else, run out of its timeslice…) the
   priority 5 thread get resumed from where it preempted.

… and has now to recognize that it could’t handle its task in a
timely manner.

[ clip … ]

So to me, the BIG QUESTION is why “NOT TO” use the floating priority
resource manager.

I made only a question mark behind the general use of floating priorities.
I don’t believe that the concept of bumping “themself up to make
themself important enough” is a good solution because the verification
of such a system would be very difficult.

Armin

[Armin_Steinhoff1]

Igor Kovalenko wrote:

“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:at7774$9gh$> 1@inn.qnx.com> …

[ clip …]



“conventional wisdom” or the common sense says also that there must be a
lower bound for the resource manager priority … so no simple user
application could push down the priority of an important resource
manager to a level where every simple user application could pre-empt
the resource manager.


If the resmgr is multithreaded

Yes … only IF the resmgr is multithreaded.

and only the thread serving a request from
low-priority client inherits the low priority then I don’t see anything
wrong with preempting that thread by another user application with ‘normal’
priority.

There are probably some single clients which doesn’t get their
appropriate service … who cares

I think the reason QNX4 has resmgrs with no priority inheritance is because
QNX4 does not support threads, so they had to protect ‘vital’ resmgrs from
flood of low-priority clients.

But it was possible to receive messages in priority order together with
boosting the priority of the resmgr.

Is receiving in priority order possible with QNX6??

This does not apply to QNX6.

IMHO … that’s only true in some special cases.

Armin

[David_Gibbs1]

Armin Steinhoff <a-steinhoff@web.de> wrote:

Igor Kovalenko wrote:
I think the reason QNX4 has resmgrs with no priority inheritance is because
QNX4 does not support threads, so they had to protect ‘vital’ resmgrs from
flood of low-priority clients.

But it was possible to receive messages in priority order together with
boosting the priority of the resmgr.

Is receiving in priority order possible with QNX6??

All messages and pulses are received in priority order under
QNX6.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Xiaodan_Tang1]

Armin Steinhoff <a-steinhoff@web.de> wrote in message
news:at8bmh$jg5$1@inn.qnx.com…

Xiaodan Tang wrote:

1. it drop to 5 to service it’s priority 5 client;

Once the priority 15 client MsgSend() to the manager, since there is no
one
waiting to receive the message, the resource manager priority will be
BUMPED UP

or better boosted

to 15 for the rest of it’s run (even though it is service a priority 5
client).

if the resource manager is multi threaded.

1. it drop to 5 to service the priority 5 client, once priority 15
   reqeust
   comming in,
   priority 5 thread preempted, priority 15 thread run (to service the
   priority 15 client)
   when it is done (block on sth else, run out of its timeslice…) the
   priority 5 thread get resumed from where it preempted.

… and has now to recognize that it could’t handle its task in a
timely manner.

No. it will not. But this is what the designer asking for. He “Designed” one
client in priority 5, and another one in priority 15, what exactly means
the “priority 15” guy is much important and should be handled as quick
as possiable.

If the designer want a “first come first serve” order, then he will make the
2 clients in SAME priority, they will then handled in time order.

If the designer still decided He CAN NOT put 2 clients in same priority,
(usually you should ask your BIG QUESTION here, why?). he have the
choice to boost drop priority (in client or in server), or he can choose
to FIX the priority in manager and take the risk that “priority inversion”
could happened to his system, while his system is far far away in galaxy

-xtang

[Armin_Steinhoff1]

Xiaodan Tang wrote:

… and has now to recognize that it could’t handle its task in a
timely manner.


No. it will not.

I’m realy not convinced.

But this is what the designer asking for. He “Designed” one
client in priority 5, and another one in priority 15, what exactly means
the “priority 15” guy is much important and should be handled as quick
as possiable.

Yes … this happens at application level but it effects also
system level threads.

Just to make a little bit clearer what my discomfort with unlimited
floating priorities are:

• there is no guidance in assigning of priorities to interrupt threads.
  ( leads to a real chaos in the design of resmgrs)

• each simple application can run with a prio up to 32 … so every
  interrupt thread has to run at least at a priority of 33 in order to
  avoid pre-emption by application threads. The same is valid for the
  pulses sent by interrupt handlers … the pulses should not drop the
  the prio of the interrupt thread under the level of 32!!

But this isn’t a design convention … and the chaos will increase
if there are more than 64 priority levels (e.g. 256)

• every application thread can drop the priortity of a message handler
  down to an arbitrary priority … this could effect the work of
  a resmgr.

What are the arguments against a lower limit of the prio of a resmgr?
(The prio of the client will just ‘boosted’ for a limited time by the
resmgr … so the resmgr can handle critical resources in a
predictable environment …)

Just my concerns

Armin



If the designer want a “first come first serve” order, then he will make the
2 clients in SAME priority, they will then handled in time order.

If the designer still decided He CAN NOT put 2 clients in same priority,
(usually you should ask your BIG QUESTION here, why?). he have the
choice to boost drop priority (in client or in server), or he can choose
to FIX the priority in manager and take the risk that “priority inversion”
could happened to his system, while his system is far far away in galaxy >

-xtang