This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Question about how to define/seek exact determinism with multiprocessors

For the record this seems to be one of those "issues" you either understand why someone can be quite obsessed about it, or else you think it doesn't even merit discussion, and please understand if you're in the latter camp you're clearly part of the problem! Now for the record I'm talking about the kind of "determinism" that is "designed into" RTCA DO-178C Design Assurance Level A (which is the FAA-mandated standard for any software designed to be  used for human-rated flight). I was able to stay employed for the better part of a decade helping people build avionics subsystems to DO-178C DAL A, we were doing things like jet engine control using (now) relatively ancient architectures like the single-processor MPC555. I was also sometimes involved writing software to do signal processing with DSPs that had a VLIW-style architecture (56X00 and Shard), and if you can't keep the processing loop size deterministic the net effect is to superimpose hideous amounts of jitter and noise on the computed signal. So pretty much all of the chips I talked about having used are getting pretty "long in the tooth", meantime along comes the ARM RP2040 from Broadcom at a list price of $.70...I guess it has a lot of potential (and certainly the older processors will be rendered totally con-competitive and will disappear) but now more than ever the people doing designs like mine need a deterministic output, ideally it should be "naturally" deterministic but if there exists a mechanism under which you could in effect create "synthetic determinism" (maybe by cutting down to a single processor for some small par of the signal processing window?) you MIGHT be able to salvage some usability out of such an architecture.

The thing about all this is, you wind up having to "be an expert on" a seemingly limitless variety of subjects in order to just make an intelligent discussion out of this! In order to even talk about determinism you need to be able to talk about how many levels of cache are present and how to 'flush" them  (because it stands to reason that "dirty" cache is one of the enemies of determinism). Now in the "bad old" days nobody wanted to pay for a license for a "certified" RTOS, so we felt free to run "on bare metal" and write simple interrupt service routines as the need arose. Nowadays people seem to have no trouble getting their hands on an RTOS they didn't write and so can't easily make functional changes to...also these RTOSes were written by people who understood not only the detailled architecture of the chip they were writing it for, but also of the chip's security model, which (for very obvious reasons) is also at least partially proprietary so shrouded in secrecy. I've even perused the website of one Green Hills software, now it's their assertion that SMP is not a reasonable "model" for deterministic processing, they have developed a concept called BMP but everything they do business about is licensed. And there's other considerations, I understand even this smallest of chips has DMA, does that help matters at least from the signal processing standpoint? (The notion of having to become a system security and secure RTOS expert JUST to get some determinism on a project is both galling and frustrating.)

I know it seems as if I've asked a lot of questions here, but really I've just scratched the surface. How does the quest for determinism vary across the various ARM processor families? Are there any open-source RTOSes that have absolute determinism as a goal? Are there any studies of scholarly works that discuss this issue in depth so I can just read it and not have to come in here and bug everybody else? If now why doesn't some heavy-hitter CS school do such a study and publish it? 

Thank you for reading this, I've asked these same questions in other forums, and so far there hasn't been enough expertise to warrant a single reply...so sad!