[gmpi] Re: Topic 5: Threading
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 11 Apr 2003 14:17:21 +0200
On Thursday 10 April 2003 20.54, Angus F. Hewlett wrote:
[...]
> With regards to hard-realtime systems on an x86, how do they handle
> this? Is it just a case of being very conservative about how much
> one attempts to run, and, in particular, making sure all the code
> and data will fit in L2 or is at least prefetched, or...?
It depends on the requirements. If you don't need heavy calculations,
it's basically as simple as designing the system so you meet the
deadline even if you're hit by all "latency generators" at once. If
you're dealing with microseconds on x86 hardware, you may have to use
some tricks to keep cache misses from causing trouble.
If the latency requirements are moderate or not an issue, but very low
jitter is required (common in systems with periodic threads), you may
enter the scheduler early, pull the thread's data into the cache and
then wait for the exact time before actually entering the thread.
AFAIK, both RTAI and RTLinux supports this. This is really rather
irrelevant with buffered I/O, though. It's a trick you use when you
have unbuffered I/O devices that are driven directly by the software
rather than by hardware timers.
If you need lots of CPU time, the same basic rules still apply, but it
gets harder to get it right in real life. If you use more CPU time,
the margins shrink - and just to make life even harder, applications
that use more CPU power generally are more complex, and thus, it gets
harder to figure out the absolute worst case execution times of all
code paths.
The easiest way to deal with this is to simply avoid "smart"
optimizations with conditionals, and just do everything all the time
as far as possible. (Somewhat like SIMD programming; use masks
instead of conditional jumps for data flow control.) That way you can
at least expect measured performance not to be too far from the worst
case. For many applications, hours of stress testing and then
designing for the measured worst case + some margin is sufficient.
For applications where missed deadlines may result in people getting
injured or killed, you obviously need to use proper verification
methods, as well as hardware fallbacks and/or multiple systems
running in parallel. At this level, you can't trust *anything* to
work reliably enough - and that includes the hardware. You might want
to put studio recording systems in this category if you have very
violent clients. ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
