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
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(;
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