sched_yield() ? good : bad

I have a coding style question. I don’t quite know how to word this very
well so quick and to the point is what ill do.

Is “sched_yield()” a function call that is look down upon?, like a “goto”
statement? Or is it considered just another everyday function call.

I understand something like this can be a burden to the system,

setprio(getpid(), 63)
for(;:wink:
sched_yield();

and the context switching from one process/thread to another can eat up alot
of cpu time, but that’s only if the call isn’t used
correctly (but I can think of a couple of times in my life that a “goto”
statement was in order but i didn’t use it).

demian

Demian <damient@wave.home.com> wrote:

I have a coding style question. I don’t quite know how to word this very
well so quick and to the point is what ill do.

Is “sched_yield()” a function call that is look down upon?, like a “goto”
statement? Or is it considered just another everyday function call.

I understand something like this can be a burden to the system,

setprio(getpid(), 63)
for(;:wink:
sched_yield();

and the context switching from one process/thread to another can eat up alot
of cpu time, but that’s only if the call isn’t used
correctly (but I can think of a couple of times in my life that a “goto”
statement was in order but i didn’t use it).

I’m not sure sched_yield() will do what you think it does. If you haven’t
read the System Architecture Guide section on Thread scheduling, you should
probably do so.

Effectively, what sched_yield() does is move the thread that calls it from
the head of the queue at its priority to the end of the queue at its
priority. This means, it gives other threads at the SAME priority a chance
to run. Lower priority threads will still never run.

Also, it is generally a bad style, not in and of itself, but because it
implies you are doing a busy loop or polling style of code.

The general recommend architecture for a QNX process is:
loop
block waiting for an event
process that event
end loop

Where the “block waiting for an event” varies inform – very often
it is MsgReceive() [possibly hidden in a library, say dispatch_block()],
but it could be InterruptWait(), sigwaitinfo(), select() or others. As
soon as you need to use sched_yield(), it implies you don’t have a
blocked state somewhere in your main flow of control.

-David

QNX Training Services
dagibbs@qnx.com

Actually, I don’t think that code will be much of a burden to the
system, the loop shown will only use a small fragment of cpu time, every
timeslice (this would amount to very little cpu time). The question I
think is why (from a design point of view) would you want to do this ?
Typically everything in a real-time system should be structured as
follows:

// client
while still_running
send a request
send another request
endwhile

// server
while still_running
receive a message
do something with it
reply to the message
endwhile

Everything I have ever written is some variation on this model, this is
true in QNX6, QNX4 and QNX2. I have never come across a design that
required sched_yield. There is typically no reason to call sched_yield
(I think it’s entire reason for being is so that context switch
benchmarks can be done :slight_smile:

There is another basic variation that goes like this (in this model the
clients of the server are both requesters and workers):

// client (worker process)
while still_running
send a message
act on reply
endwhile

// server
while still_running
receive a message
if worker and something to_do then
reply with operation
else if !worker
do something
reply
endif
endwhile

-----Original Message-----
From: Demian [mailto:damient@wave.home.com]
Posted At: Thursday, March 08, 2001 12:09 PM
Posted To: os
Conversation: sched_yield() ? good : bad
Subject: sched_yield() ? good : bad


I have a coding style question. I don’t quite know how to word this
very
well so quick and to the point is what ill do.

Is “sched_yield()” a function call that is look down upon?, like a
“goto”
statement? Or is it considered just another everyday function call.

I understand something like this can be a burden to the system,

setprio(getpid(), 63)
for(;:wink:
sched_yield();

and the context switching from one process/thread to another can eat up
alot
of cpu time, but that’s only if the call isn’t used
correctly (but I can think of a couple of times in my life that a “goto”
statement was in order but i didn’t use it).

demian

Rennie Allen <RAllen@csical.com> wrote:

Actually, I don’t think that code will be much of a burden to the
system, the loop shown will only use a small fragment of cpu time, every
timeslice (this would amount to very little cpu time).

Actually, it could be completely nasty. He sets the priority to 63,
the highest. If there is nothing else at 63, then it will use ALL the
cpu time that isn’t handling interrupts. Timeslice is irrelevant to
this issue – timeslice only has one meaning, if a RR scheduled program
has run for its entire time slice, it will be moved to the end of the
queue and that point (effectively, it will have a sched_yield() call
imposed on it). If there is nothing else at that priority (and most
things won’t normally be run at priority 63), it can and will use all
the CPU time – you only share CPU with people at your own priority
when RR, anything lower is completely pre-empted.

Of course, if he might be running everything at priority 63… but
I wouldn’t want to see the system.

-David

QNX Training Services
dagibbs@qnx.com

Thanks for pointing this out.

I saw the priority as 63 and associated higher numbers with lower
priority (there are downsides to having used QNX2 extensively in the
past :slight_smile:. Being the lowest priority would be typical for a thread which
loops without blocking. In this scenerio, the sched_yield would steal
very few cycles from other threads at the same prio, and none from any
threads at a higher prio (thus it would use very little CPU overall).
My point was that there should never be a need for polling, even at the
lowest priority.

The rest of my post (which was the major point) is accurate.

-----Original Message-----
From: David Gibbs [mailto:dagibbs@qnx.com]
Posted At: Friday, March 09, 2001 12:32 PM
Posted To: os
Conversation: sched_yield() ? good : bad
Subject: Re: sched_yield() ? good : bad


Rennie Allen <RAllen@csical.com> wrote:

Actually, I don’t think that code will be much of a burden to the
system, the loop shown will only use a small fragment of cpu time,
every
timeslice (this would amount to very little cpu time).

Actually, it could be completely nasty. He sets the priority to 63,
the highest. If there is nothing else at 63, then it will use ALL the
cpu time that isn’t handling interrupts. Timeslice is irrelevant to
this issue – timeslice only has one meaning, if a RR scheduled program
has run for its entire time slice, it will be moved to the end of the
queue and that point (effectively, it will have a sched_yield() call
imposed on it). If there is nothing else at that priority (and most
things won’t normally be run at priority 63), it can and will use all
the CPU time – you only share CPU with people at your own priority
when RR, anything lower is completely pre-empted.

Of course, if he might be running everything at priority 63… but
I wouldn’t want to see the system.

-David

QNX Training Services
dagibbs@qnx.com

so, the answer to the question is?

  1. if you can get away with telling people you going to use it in a design
    meeting and everybody agrees (or doesn’t notice) then use it,

  2. never use it, its a bad thing,

  3. use it all the time,

  4. the pc will melt if i use it in a nasty way, so be careful

Thank you have a good day

demian

I use it in a
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C90319B4@exchangecal.hq.csical.com

Thanks for pointing this out.

I saw the priority as 63 and associated higher numbers with lower
priority (there are downsides to having used QNX2 extensively in the
past > :slight_smile:> . Being the lowest priority would be typical for a thread which
loops without blocking. In this scenerio, the sched_yield would steal
very few cycles from other threads at the same prio, and none from any
threads at a higher prio (thus it would use very little CPU overall).
My point was that there should never be a need for polling, even at the
lowest priority.

The rest of my post (which was the major point) is accurate.

-----Original Message-----
From: David Gibbs [mailto:> dagibbs@qnx.com> ]
Posted At: Friday, March 09, 2001 12:32 PM
Posted To: os
Conversation: sched_yield() ? good : bad
Subject: Re: sched_yield() ? good : bad


Rennie Allen <> RAllen@csical.com> > wrote:

Actually, I don’t think that code will be much of a burden to the
system, the loop shown will only use a small fragment of cpu time,
every
timeslice (this would amount to very little cpu time).

Actually, it could be completely nasty. He sets the priority to 63,
the highest. If there is nothing else at 63, then it will use ALL the
cpu time that isn’t handling interrupts. Timeslice is irrelevant to
this issue – timeslice only has one meaning, if a RR scheduled program
has run for its entire time slice, it will be moved to the end of the
queue and that point (effectively, it will have a sched_yield() call
imposed on it). If there is nothing else at that priority (and most
things won’t normally be run at priority 63), it can and will use all
the CPU time – you only share CPU with people at your own priority
when RR, anything lower is completely pre-empted.

Of course, if he might be running everything at priority 63… but
I wouldn’t want to see the system.

-David

QNX Training Services
dagibbs@qnx.com

Rennie Allen wrote:

Thanks for pointing this out.

I saw the priority as 63 and associated higher numbers with lower
priority (there are downsides to having used QNX2 extensively in the
past > :slight_smile:> . Being the lowest priority would be typical for a thread which
loops without blocking. In this scenerio, the sched_yield would steal
very few cycles from other threads at the same prio, and none from any
threads at a higher prio (thus it would use very little CPU overall).
My point was that there should never be a need for polling, even at the
lowest priority.

There is the case of broken hardware whose interrupts don’t work. Sometimes
there just isn’t alternative hardware available.

so, the answer to the question is?

  1. if you can get away with telling people you going to use it in a
    design
    meeting and everybody agrees (or doesn’t notice) then use it,

If everyone agrees to use polling at your design meeting, then by all
means
do so; and quickly start looking for a different design team to work
with.