On Fri, Jun 6, 2008 at 2:29 PM, Tim Gessner <tim@deltacompsys.com> wrote:

> I create several threads, each performing a different task.  Each task has
> a different interval time.  So one task needs to run every n1 milliseconds,
> another task needs to run every n2 milliseconds, etc.
>
> I had this running with simple usleep calls and one task with a higher
> priority than the others.  Everything worked but I wasn't happy with the
> timing of the tasks, etc.
>
> So I tried to implement a timer for each task, using timer_create and a
> message pulse.  Again everything worked EXCEPT I cannot set the priority of
> the one task.  It says at 10 no matter what I do.
>
> It appears that after blocking on MsgReceive the task's priority is reset
> to 10.  I assumed that messages would have priority queues.  I thought that
> if the timer timed out and there was no available processor the high
> priority task who now has a message pulse pending would preempt a lower
> priority thread.  That was part of the value of using message pulses rather
> than SIGEV_SIGNAL_THREAD.


A blocked thread has no meaningfull priority.  Priorities only matter if
things are running:
http://sendreceivereply.wordpress.com/2007/05/02/can-you-wait-a-little-bit-faster/

Now the events that you are registering with the timers can have priorities
associated with them.  For example if you
are using pulses, then you can assign priorities to the pulses and when
'whatever thread receives them' comes out
of MsgReceive() then it will float to the priority of the pulse that was
sent.

... unless you created a fixed priority channel, but you would have to go
out of your way to do that.

You are correct about the pre-emption, if messages/pulses are being handled
by different threads then the
instant a higher priority message is dispatched and received by a thread (ie
a thread in MsgReceive()) then
that thread will run and the other threads will go READY.

However, if you only have a fixed number of threads (ie 1) servicing
messages on a channel, and those threads
are busy already servicing messages, so no thread is waiting in
MsgReceive(), then what happens is that when
a high priority message comes in the thread(s) are boosted to run at that
"high priority" so that the high priorty
pulse/message can be serviced.

You may want to take a read through:
http://qnx.com/developers/docs/6.3.2/neutrino/sys_arch/about.html

In particular the section on the MicroKernel and then the IPC and Priority
management.

Hope this helps,
 Thomas



>
>
> What am I misunderstanding?  Am I completely off track?
>
> Thanx
> Tim
>
> _______________________________________________
> OSMeta
> http://community.qnx.com/sf/go/post8847
>
>