dispatch_block() and dispatch_handle() using select_attach()

Hello experts,
we have the following situation:

a simple server creates a dispatcher using dispatch_create() and then
calls select_attach() for an opened fd (ResMgr) to get notified for input
condition.
The main thread (prio 26) sits in a loop using dispatch_block() and
dispatch_handle().
If the main thread becomes unblocked from dispatch_block(), the
main thread has prio 10 !!! and calls dispatch_handle() with this prio,
which results
in a select callback with prio 10!

Why ??? What I’m doing wrong ?


cheers, peter

Hi Peter

This is expected, and usually desirable behavior. By default any QNX
message passing server (this includes resource managers) will inherit the
priority of the highest priority client that is sending to it. This is done
to help alleviate priority inversion problems.

For more info, see the “Description” section of the doc for ChannelCreate().

Prio. inheritance can be turned off by specifiying _NTO_CHF_FIXED_PRIORITY
as part of the flags arg. to ChannelCreate().

“Peter” <nospam@nospam.at.all> wrote in message
news:bvtj73$464$1@inn.qnx.com

Hello experts,
we have the following situation:

a simple server creates a dispatcher using dispatch_create() and then
calls select_attach() for an opened fd (ResMgr) to get notified for input
condition.
The main thread (prio 26) sits in a loop using dispatch_block() and
dispatch_handle().
If the main thread becomes unblocked from dispatch_block(), the
main thread has prio 10 !!! and calls dispatch_handle() with this prio,
which results
in a select callback with prio 10!

Why ??? What I’m doing wrong ?


cheers, peter

Yes Chris, thanks, I know this mechanism.
But our server (prio26) opens a device (the fd to get the notification for)
which also runs w/ prio 26.
The informed server is started w/ prio 26 and then registers a callback
using select_attach().
Why does the notifying RM (prio26 too!) reduces the priority of a thread
which was started w/ prio 26?

In other words:
Two processes, each w/ only ONE thread, each w/ prio 26 communicate by
using select_attach()
and after the first dispatch_unblock() the notified process drops to prio 10
!
From my point of view this creates a priority inversion!

I assume, the call to select_attach() creates an event and uses ionotify()
internally…right ?
What is the type of event (a pulse?) and which prio is set to the event for
delivery?

TIA,
Peter

“Chris Foran” <cforan@qnx.com> schrieb im Newsbeitrag
news:c003l4$74o$1@inn.qnx.com

Hi Peter

This is expected, and usually desirable behavior. By default any QNX
message passing server (this includes resource managers) will inherit the
priority of the highest priority client that is sending to it. This is
done
to help alleviate priority inversion problems.

For more info, see the “Description” section of the doc for
ChannelCreate().

Prio. inheritance can be turned off by specifiying _NTO_CHF_FIXED_PRIORITY
as part of the flags arg. to ChannelCreate().

“Peter” <> nospam@nospam.at.all> > wrote in message
news:bvtj73$464$> 1@inn.qnx.com> …
Hello experts,
we have the following situation:

a simple server creates a dispatcher using dispatch_create() and then
calls select_attach() for an opened fd (ResMgr) to get notified for
input
condition.
The main thread (prio 26) sits in a loop using dispatch_block() and
dispatch_handle().
If the main thread becomes unblocked from dispatch_block(), the
main thread has prio 10 !!! and calls dispatch_handle() with this prio,
which results
in a select callback with prio 10!

Why ??? What I’m doing wrong ?


cheers, peter
\

Ping …


“Peter Weber” <nospam@nospam.at.all> schrieb im Newsbeitrag
news:c06kkh$qe9$1@inn.qnx.com

Yes Chris, thanks, I know this mechanism.
But our server (prio26) opens a device (the fd to get the notification
for)
which also runs w/ prio 26.
The informed server is started w/ prio 26 and then registers a callback
using select_attach().
Why does the notifying RM (prio26 too!) reduces the priority of a thread
which was started w/ prio 26?

In other words:
Two processes, each w/ only ONE thread, each w/ prio 26 communicate by
using select_attach()
and after the first dispatch_unblock() the notified process drops to prio
10
!
From my point of view this creates a priority inversion!

I assume, the call to select_attach() creates an event and uses ionotify()
internally…right ?
What is the type of event (a pulse?) and which prio is set to the event
for
delivery?

TIA,
Peter

“Chris Foran” <> cforan@qnx.com> > schrieb im Newsbeitrag
news:c003l4$74o$> 1@inn.qnx.com> …
Hi Peter

This is expected, and usually desirable behavior. By default any QNX
message passing server (this includes resource managers) will inherit
the
priority of the highest priority client that is sending to it. This is
done
to help alleviate priority inversion problems.

For more info, see the “Description” section of the doc for
ChannelCreate().

Prio. inheritance can be turned off by specifiying
_NTO_CHF_FIXED_PRIORITY
as part of the flags arg. to ChannelCreate().

“Peter” <> nospam@nospam.at.all> > wrote in message
news:bvtj73$464$> 1@inn.qnx.com> …
Hello experts,
we have the following situation:

a simple server creates a dispatcher using dispatch_create() and then
calls select_attach() for an opened fd (ResMgr) to get notified for
input
condition.
The main thread (prio 26) sits in a loop using dispatch_block() and
dispatch_handle().
If the main thread becomes unblocked from dispatch_block(), the
main thread has prio 10 !!! and calls dispatch_handle() with this
prio,
which results
in a select callback with prio 10!

Why ??? What I’m doing wrong ?


cheers, peter


\

Peter Weber <nospam@nospam.at.all> wrote:

Ping …

I think this has been answered for you elsewhere, but in case anyone
is watching:

select_attach() uses an (undocumented, hack) pulse priority of -1
to say use the “process’s priority” for this pulse. Yeah, the
process’s priority. This is set to the priority the process had
at creation time, that is, the priority of the thread that created
the process, and doesn’t change.

The following (undocumented, hack) will set the process priority to
26:

struct sched_param;
sched_param.sched_priority = 26;
sched_param.sched_curpriority = 26; /* think only first is needed */
SchedSet( 0, -1, SCHED_NOCHANGE, &sched_param );

-David

“Peter Weber” <> nospam@nospam.at.all> > schrieb im Newsbeitrag
news:c06kkh$qe9$> 1@inn.qnx.com> …
Yes Chris, thanks, I know this mechanism.
But our server (prio26) opens a device (the fd to get the notification
for)
which also runs w/ prio 26.
The informed server is started w/ prio 26 and then registers a callback
using select_attach().
Why does the notifying RM (prio26 too!) reduces the priority of a thread
which was started w/ prio 26?

In other words:
Two processes, each w/ only ONE thread, each w/ prio 26 communicate by
using select_attach()
and after the first dispatch_unblock() the notified process drops to prio
10
!
From my point of view this creates a priority inversion!

I assume, the call to select_attach() creates an event and uses ionotify()
internally…right ?
What is the type of event (a pulse?) and which prio is set to the event
for
delivery?

TIA,
Peter

“Chris Foran” <> cforan@qnx.com> > schrieb im Newsbeitrag
news:c003l4$74o$> 1@inn.qnx.com> …
Hi Peter

This is expected, and usually desirable behavior. By default any QNX
message passing server (this includes resource managers) will inherit
the
priority of the highest priority client that is sending to it. This is
done
to help alleviate priority inversion problems.

For more info, see the “Description” section of the doc for
ChannelCreate().

Prio. inheritance can be turned off by specifiying
_NTO_CHF_FIXED_PRIORITY
as part of the flags arg. to ChannelCreate().

“Peter” <> nospam@nospam.at.all> > wrote in message
news:bvtj73$464$> 1@inn.qnx.com> …
Hello experts,
we have the following situation:

a simple server creates a dispatcher using dispatch_create() and then
calls select_attach() for an opened fd (ResMgr) to get notified for
input
condition.
The main thread (prio 26) sits in a loop using dispatch_block() and
dispatch_handle().
If the main thread becomes unblocked from dispatch_block(), the
main thread has prio 10 !!! and calls dispatch_handle() with this
prio,
which results
in a select callback with prio 10!

Why ??? What I’m doing wrong ?


cheers, peter



\


David Gibbs
dagibbs@qnx.com

thanks david. that helps to identify my problem.

David Gibbs wrote:

Peter Weber <> nospam@nospam.at.all> > wrote:

Ping …


I think this has been answered for you elsewhere, but in case anyone
is watching:

select_attach() uses an (undocumented, hack) pulse priority of -1
to say use the “process’s priority” for this pulse. Yeah, the
process’s priority. This is set to the priority the process had
at creation time, that is, the priority of the thread that created
the process, and doesn’t change.

The following (undocumented, hack) will set the process priority to
26:

struct sched_param;
sched_param.sched_priority = 26;
sched_param.sched_curpriority = 26; /* think only first is needed */
SchedSet( 0, -1, SCHED_NOCHANGE, &sched_param );

-David


“Peter Weber” <> nospam@nospam.at.all> > schrieb im Newsbeitrag
news:c06kkh$qe9$> 1@inn.qnx.com> …

Yes Chris, thanks, I know this mechanism.
But our server (prio26) opens a device (the fd to get the notification

for)

which also runs w/ prio 26.
The informed server is started w/ prio 26 and then registers a callback
using select_attach().
Why does the notifying RM (prio26 too!) reduces the priority of a thread
which was started w/ prio 26?

In other words:
Two processes, each w/ only ONE thread, each w/ prio 26 communicate by
using select_attach()
and after the first dispatch_unblock() the notified process drops to prio

10

!
From my point of view this creates a priority inversion!

I assume, the call to select_attach() creates an event and uses ionotify()
internally…right ?
What is the type of event (a pulse?) and which prio is set to the event

for

delivery?

TIA,
Peter

“Chris Foran” <> cforan@qnx.com> > schrieb im Newsbeitrag
news:c003l4$74o$> 1@inn.qnx.com> …

Hi Peter

This is expected, and usually desirable behavior. By default any QNX
message passing server (this includes resource managers) will inherit

the

priority of the highest priority client that is sending to it. This is

done

to help alleviate priority inversion problems.

For more info, see the “Description” section of the doc for

ChannelCreate().

Prio. inheritance can be turned off by specifiying

_NTO_CHF_FIXED_PRIORITY

as part of the flags arg. to ChannelCreate().

“Peter” <> nospam@nospam.at.all> > wrote in message
news:bvtj73$464$> 1@inn.qnx.com> …

Hello experts,
we have the following situation:

a simple server creates a dispatcher using dispatch_create() and then
calls select_attach() for an opened fd (ResMgr) to get notified for

input

condition.
The main thread (prio 26) sits in a loop using dispatch_block() and
dispatch_handle().
If the main thread becomes unblocked from dispatch_block(), the
main thread has prio 10 !!! and calls dispatch_handle() with this

prio,

which results
in a select callback with prio 10!

Why ??? What I’m doing wrong ?


cheers, peter




\