8 ms·
> it was generally non-deterministic This is basically it. People who have never worked on actual real-time systems just never seem to get that in those enviro
by notacoward 7y ago
> it was generally non-deterministic
This is basically it. People who have never worked on actual real-time systems just never seem to get that in those environments determinism often matters more than raw performance. I don't know about "soft" real-time (e.g. games, or audio/video) but in "hard" real-time (e.g. avionics, industrial control) it's pretty routine to do things like disable caches and take a huge performance hit for the sake of determinism. If you can run 10% faster but miss deadlines 0.1% more often, that's a fail. It's too easy for tyros to say pauses don't matter. In many environments they do.
- Skunkleton 7y agoIts not just pauses either. Non-deterministic memory usage is a big deal too.
- GuB-42 7y agoI have actually worked on a system where malloc() was forbidden. In fact it always returned null. Buffers were all statically allocated and stack usage was kept to a minimum (it was only a few kB anyways). The software was shipped with a memory map file so you know exactly what each memory address is used for. A lot of test procedures involved reading and writing at specific memory locations. It was for avionics BTW. As you may have guessed, it was certified code with hard real time constraints. Exceeding the cycle time is equivalent to a crash, causing the watchdog to trigger a reset.
- aetherspawn 7y agoI’d be interested in knowing more if you care to write more about this. I’m currently costing/scoping out what’s required in writing software at that level but don’t really have some real industry insight into what other people do Static memory is something we already do but we’re pretty interested whether industry actually adopts redundant code paths, monitors, to what extent watchdogs (how many cycles can be missed?), etc.
- rramadass 7y agoI suggest you take a look at the books by Michael Pont and the offerings through his company "SafeTTy Systems". His/Company's work deals with hard real-time systems with all the associated standards.
- hackits 7y agoSounds very similar to NASA C programming guidelines. Each module during the initialization period would allocate its static memory size. Every loop had a upper bound's max iteration to prevent infinite loops. I think they posted the guidelines and it was a wonderful read about how they developed real time systems.
- mike00632 7y agoDo you happen to have a link to the guidelines?
- hackits 7y agohttp://spinroot.com/gerard/pdf/P10.pdf http://spinroot.com/gerard/pdf/P10.pdf
- neop1x 7y agoI was wondering why I couldn't open this pdf on my android pdf viewer and this link gives me cloudflare's captcha. It uses google's ReCaptcha - storefronts, bicycles, semaphores. What a terrible practice. People stop overusing cloudflare!
- kimown 7y agohttps://ntrs.nasa.gov/search.jsp?R=19950022400 https://ntrs.nasa.gov/search.jsp?R=19950022400 http://mechatronics.me.wisc.edu/labresources/DataSheets/NASA-GSFC_C_Programming_Styles-94-003.pdf http://mechatronics.me.wisc.edu/labresources/DataSheets/NASA...
- loeg 7y agoWhy even define a malloc() in this environment if it always returns NULL?
- drblast 7y agoSo you crash immediately if someone tries to use it or a library gets added that does? Never experienced the malloc() thing but do throw exceptions and fail fast under conditions like these so they're caught in testing.
- seanmcdirmid 7y agoBecause even if you don't use it directly, you might use some code that uses it. And even then, it might not ever be called given the way you are reusing the code, so...a dynamic check is the best way to ensure it never actually gets used.
- loeg 7y ago> Because even if you don't use it directly, you might use some code that uses it. It seems extremely unlikely that any general purpose code you might adopt, which happens to invoke malloc() at all, would be fit for purpose in such a restricted environment without substantial modification; in which case you would just remove the malloc() calls as well. > And even then, it might not ever be called given the way you are reusing the code, so...a dynamic check is the best way to ensure it never actually gets used. In such a restricted environment, it is unlikely you just have unknown deadcode in your project. "Oh, those parts that call malloc()? They're probably not live code and we'll find out via a crash at runtime." That's like the opposite of what you want in a hard realtime system. So, no — a static, compile/link time check is a strictly superior way to ensure it never gets used.
- Impossible 7y agoMalloc was forbidden in a AAA title I worked on. Interestingly enough we also had two (!!!) embedded garbage collected scripting languages that could only allocate in small (32MB, 16 MB) arenas and would assert if they over allocated.
- zippie 7y agoIn modern C libraries malloc is mmap’ed anon pages underneath for an increasingly larger set of conditions these days.
- drudru11 7y agoWow - disabling the caches is an extreme measure. I get it though. After doing that, you can (probably) do cycle counting on routines again. Just like the 80s or earlier.
- viraptor 7y agoI don't. Maybe we're thinking about different kind of caches, but if these are transparent, no-performance-impact caches, then why wouldn't you prove the system works well with caches off (guarantee deadlines are met), then enable caches for opportunistic power gains?
- piaste 7y agoWho will provide a guarantee that the caches are truly transparent and will not trigger any new bugs? Essentially, you would need to prove the statement "if a system works well with caches off, then it works well with caches on" to the satisfaction of whatever authority is giving you such stringent requirements.
- squeaky-clean 7y agoYou'd have to very solidly prove that in the wors-case a cache only ever make execution time equal to or faster than a processor not using cache and never causes anything to be slower.
- darnir 7y agoEven that is not enough. The cache may make everything faster, but it could lead to higher contention on a different physical resource slowing things down there. The cache cannot be guaranteed to prevent that.
- Baeocystin 7y agoBecause you lose deterministic behavior, and there are cases where that is non-negotiable, regardless of performance cost.
- notacoward 7y ago
- PorterDuff 7y ago""soft" real-time (e.g. games, or audio/video) " Hah. Who sez that audio and video products have 'soft' real time? Go on now.
- detaro 7y agoWhat percentage of the market is A/V build to actual hard real-time standards, and not expected to run on devices that can't provide it (so no PCs with normal OSes, no smartphones)? For the vast majority, soft real-time is fine, since an occasional deadline-miss results in minor inconvenience, not property damage, injury or death. I assume some dedicated devices are more or less hard real time, due to running way simpler software stacks on dedicated hardware.
- PorterDuff 7y agoI take it that scarcely anyone here has written software for video switchers, routers, DVEs, linear editors, audio mixers, glue products, master control systems, character generators, etc. etc. Missing a RT schedule rarely results in death, but you'd think so given the attitude from the customer. That's a silly definition for it. There's a whole world out there of hard real time, the world is not simply made up of streaming video and cell phones. The cool thing on HN is you can get down voted for simply making that observation. It's a sign of the times I'm afraid.
- fastball 7y agoYou just agreed with the OC. RT video/audio failing never results in death. Where as failures in "avionics, industrial control" absolutely can / do. That seems to be where OC was drawing the line.
- detaro 7y agoSeems to be a common distinction, although GP is right with the addition that the production side of things is more demanding (and at least would suffer financial damage if problems occur to often) than the playback side formed by random consumer gear, and has some, especially low-level/synchronization-related, gear to hard standards. But often soft is enough, as long as it's reliable enough on average.