fifo scheduling strategy for threads on same priority level

Hello,

in order to obtain an exact model of my software, I need to know which
thread will be set to RUNNING in the following configuration:

first possibility of operation:

  • original situation
    “ThreadA”, P34f, RUNNING → send a message to “ThreadB”
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, READY

  • ThreadB is scheduled, gets the message and processes it
    “ThreadA”, P34f, REPLY
    “ThreadB”, P34o, RUNNING
    “ThreadC”, P34f, READY

  • ThreadB does a reply, then receive and ThreadA is scheduled
    “ThreadA”, P34f, RUNNING
    “ThreadB”, P34o, RECEIVE
    “ThreadC”, P34f, READY


    second possibility of operation:

  • original situation
    “ThreadA”, P34f, RUNNING → send a message to “ThreadB”
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, READY

  • ThreadC is scheduled
    “ThreadA”, P34f, SEND
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, RUNNING

  • ThreadC is finished and gets ready again, the message from ThreadA is
    forwarded to ThreadB
    “ThreadA”, P34f, REPLY
    “ThreadB”, P34o, RUNNING
    “ThreadC”, P34f, READY

  • ThreadB does a reply, then receive and ThreadA is scheduled
    “ThreadA”, P34f, RUNNING
    “ThreadB”, P34o, RECEIVE
    “ThreadC”, P34f, READY


    third possibility of operation:

… after ThreadB is done with the message, ThreadC is scheduled again so
that ThreadA receives the reply even later…


Is there a definite order of operation when threads at the same priority
level try to become scheduled, when a message passing is involved in the
described way?

Regards.

Nnamdi

Nnamdi Kohn <nnamdi.kohn@tu-bs.de> wrote:

Hello,

in order to obtain an exact model of my software, I need to know which
thread will be set to RUNNING in the following configuration:

What will actually happen:

  • original situation
    “ThreadA”, P34f, RUNNING → send a message to “ThreadB”
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, READY

  • ThreadB is scheduled, gets the message and processes it
    “ThreadA”, P34f, REPLY
    “ThreadB”, P34o, RUNNING
    “ThreadC”, P34f, READY

Correct. Possible issue: ThreadB is algorithm o, for SCHED_OTHER.
Currently that is the same as Round Robin, but it may change in the
future (to an adaptive or decay algorithm).

What happens next depends on something you didn’t specify. If ThreadB
exceeds it’s timeslice, the following will happen:

“ThreadA”, P34f, REPLY
“ThreadB”, P34o, READY
“ThreadC”, P34f, RUNNING

And, the system will continue in this state until ThreadC blocks.

Assuming ThreadB completes it’s work and gets a chance to reply to
ThreadA, we will get:

“ThreadA”, P34f, READY
“ThreadB”, P34o, RUNNING
“ThreadC”, P34f, READY

After ThreadB receives:

“ThreadA”, P34f, READY
“ThreadB”, P34o, RECEIVE
“ThreadC”, P34f, RUNNING

And, ThreadA won’t see the reply until ThreadC blocks/yields.

Is there a definite order of operation when threads at the same priority
level try to become scheduled, when a message passing is involved in the
described way?

Yes, there is a definite order of operation.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

Hi all,

Greetings !!

I’ m very fresh to QNX. Actually i want to read the data from an input
device and diaplay it on LED module.

The datas are stored in the form of blocks. i need to read as well as write
the data from 5th block to 15th block.(until 4 i cannt use.b’cos
manufacturer’s specific.)

Certain commands are given in the data sheet to read and write the data
from/to it. I don’t know how to send these commands to an i/p
device.(Connected Serially).

I used general read() function.It reads all.but want to get a particular
block.(i tried readblock() also. it didnt work).

Similarly, in the LED data sheets some frame format is given like SOH,Write
Access… how to send these frame formats to LED. doing program in C.

Which command i should use for this?
Thank You.


“Nnamdi Kohn” <nnamdi.kohn@tu-bs.de> wrote in message
news:dekj63$3ph$1@inn.qnx.com

Hello,

in order to obtain an exact model of my software, I need to know which
thread will be set to RUNNING in the following configuration:

first possibility of operation:

  • original situation
    “ThreadA”, P34f, RUNNING → send a message to “ThreadB”
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, READY

  • ThreadB is scheduled, gets the message and processes it
    “ThreadA”, P34f, REPLY
    “ThreadB”, P34o, RUNNING
    “ThreadC”, P34f, READY

  • ThreadB does a reply, then receive and ThreadA is scheduled
    “ThreadA”, P34f, RUNNING
    “ThreadB”, P34o, RECEIVE
    “ThreadC”, P34f, READY


    second possibility of operation:

  • original situation
    “ThreadA”, P34f, RUNNING → send a message to “ThreadB”
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, READY

  • ThreadC is scheduled
    “ThreadA”, P34f, SEND
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, RUNNING

  • ThreadC is finished and gets ready again, the message from ThreadA is
    forwarded to ThreadB
    “ThreadA”, P34f, REPLY
    “ThreadB”, P34o, RUNNING
    “ThreadC”, P34f, READY

  • ThreadB does a reply, then receive and ThreadA is scheduled
    “ThreadA”, P34f, RUNNING
    “ThreadB”, P34o, RECEIVE
    “ThreadC”, P34f, READY


    third possibility of operation:

… after ThreadB is done with the message, ThreadC is scheduled again so
that ThreadA receives the reply even later…


Is there a definite order of operation when threads at the same priority
level try to become scheduled, when a message passing is involved in the
described way?

Regards.

Nnamdi

It should be possible to see exactly what happens using the System Profiler.

What will actually happen:

  • original situation
    “ThreadA”, P34f, RUNNING → send a message to “ThreadB”
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, READY

  • ThreadB is scheduled, gets the message and processes it
    “ThreadA”, P34f, REPLY
    “ThreadB”, P34o, RUNNING
    “ThreadC”, P34f, READY

Why would ThreadB get CPU time first? ThreadC was waiting a longer time, and
when Thread B switches from Receive to Ready, it will be placed at the end
of the ready queue. Or not?


Malte

Malte Mundt <mmundt@qnx.de> wrote:

What will actually happen:

  • original situation
    “ThreadA”, P34f, RUNNING → send a message to “ThreadB”
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, READY

  • ThreadB is scheduled, gets the message and processes it
    “ThreadA”, P34f, REPLY
    “ThreadB”, P34o, RUNNING
    “ThreadC”, P34f, READY

Why would ThreadB get CPU time first? ThreadC was waiting a longer time, and
when Thread B switches from Receive to Ready, it will be placed at the end
of the ready queue. Or not?

Not. What I described is what actually happens. Saw it in the
System Profiler, went “hunh!”, went through the kernel source with
the ever helpful Adam, and found that, yup, on receive, the thread
is made ready at the head of the queue for its priority.

From looking at the CVS logs, it had been that way a long time, I think
back to about Neutrino 2.0 timeframe.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

Interesting. Thanks for the clarification.

Cheers,

Malte

“David Gibbs” <dagibbs@qnx.com> schrieb im Newsbeitrag
news:df769c$av$1@inn.qnx.com

Malte Mundt <> mmundt@qnx.de> > wrote:

What will actually happen:

  • original situation
    “ThreadA”, P34f, RUNNING → send a message to “ThreadB”
    “ThreadB”, P10o, RECEIVE
    “ThreadC”, P34f, READY

  • ThreadB is scheduled, gets the message and processes it
    “ThreadA”, P34f, REPLY
    “ThreadB”, P34o, RUNNING
    “ThreadC”, P34f, READY

Why would ThreadB get CPU time first? ThreadC was waiting a longer time,
and
when Thread B switches from Receive to Ready, it will be placed at the
end
of the ready queue. Or not?

Not. What I described is what actually happens. Saw it in the
System Profiler, went “hunh!”, went through the kernel source with
the ever helpful Adam, and found that, yup, on receive, the thread
is made ready at the head of the queue for its priority.

From looking at the CVS logs, it had been that way a long time, I think
back to about Neutrino 2.0 timeframe.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com