Post by Chris FriesenIf you are in SCHED_RR and call sched_yield(), you *will*
With the soft realtime policies,
Here come the standards again. DavidB can keep my honest on the history, but
posix groups were split between the "threads" people and the "real >
time" people, with some overlap.
In truth there were at least 3 easily identifiable "camps", but it's
also important to remember that the realtime people were the HOSTS. That
is, the thread people saw an opportunity in some realtime needs to get
threads into POSIX. All of the POSIX thread development was in the
context of the "1003.4" (realtime) working group.
The realtime people were finishing the realtime amendment, and they had
a substantial investment in the priority based scheduling policies. It
was natural for them to want those in the threads amendment as well.
When pthreads was ready, the real-time folks tried to add their API's
into the mix. They got rebuffed by some vendors ... and the RT
features were added as "Optional". You could claim pthreads conformance,
without implementing the real-time facilities.
No, the realtime interfaces were there all along. In fact the original
reference document original proposed had somewhat similar scheduling
interfaces -- priority based scheduling is hardly unique to POSIX. (And
in fact the specific POSIX base rule is to standardize "existing
practice", NOT to invent.)
It's hard to make a multiprocessor thread realtime scheduler that's also
fast; it requires a lot of synchronization that the scheduler might not
otherwise need. Realtime scheduling is an option in 1003.1b as well,
(for processes); NOT just for threads. The realtime people never
intended to force everyone to write realtime code; they only wanted to
be assured that THEY could.
It's one of the reasons we have this odd-ball functions "sched_yield",
when every threads programmer is looking for the "pthreads_" version of
that.
Oddly, I just re-explained this last week in this discussion thread; but
perhaps you missed it. There WAS a pthread_yield(). But there was also
sched_yield from the previous realtime (process) amendment. Most of the
development and balloting of the threads amendment took place on a
completely separate document. But when we got close to finalization we
went through the important exercise of creating a full POSIX document
with threads integrated. One of the trickier bits of this merge was
figuring out where in the base standard "process" should be changed to
"thread". (We're still finding places where it should have been changed
but wasn't... or even where it was changed but shouldn't have been.)
In particular, on review we noticed that because it was critical that a
POSIX system with thread support schedules threads, not processes, the
descriptions of pthread_yield() and sched_yield() were now identical
except that sched_yield existed and had meaning without threads. So
there was clearly no point in adding pthread_yield(), and it was removed
from the standard.
That people "expect" to find pthread_yield() is largely the fault of
vendors who "jumped the gun" and implemented a non-standard draft
interface. They shouldn't have done this, and it's not the fault of
POSIX or the thread working group that the final form is not the same as
those drafts. (Which were explicitly published "for review and comment
only", and distributed only to a limited audience who had a reason and
desire to review it.)
Happily, the vendor planets are lining up, and most of the major
players
have added the real-time features. You have to read the vendor docs
carefully here ... all they were required to do was implement a stub
function, so the linker wouldn't complain about the app, and to put in
some magic flags in their header files, and run-time descriptions on
whether the function was actually supported.
If realtime features aren't implemented, they're return ENOSYS; and
there are also sysconf() options and <unistd.h> symbols to detect this
at runtime or even compile time. It's not that hard, and it's not
particularly "tricky".
What was annoying was certain vendors who thought it'd be better to
CLAIM to support realtime but not bother to make the functions actually
work. (Making it difficult for developers or programs to determine
reliably whether the functions would result in any usable effect.) I
believe those implementations are becoming lost in the mists of time,
and I won't name names.
History lessons aside, I still claim that what is running on a physical
cpu is a thread, in a modern OS. How they are grouped and dispatched
is another matter.
We also agree that the standards writers have given us the proper
thought models to implement what we intend ... and many modern
apps are expoiting real-time features, including NASA scarfing
LandRover data from space.
Priority scheduling is only a rough approximation to what anyone really
wants. It's just simpler and cheaper to implement (and use) than
anything better; and better solutions tend not to be widely deployed at
this time. (And remember POSIX standarizes "existing practice".)
Managing prioritized resources is extraordinarily difficult even in a
relatively contained embedded application environment, and nearly
impossible otherwise.
It can be used productively by people who are careful enough and
determined. Don't mistake that for "correct" or "general". ;-)