Okay, now prove that your program written in Lisp will not miss cycles regardless of the data sent to it for at least the length of the mission. The issue is in being able to prove a program is deterministic. Wildcards like schedulers and garbage collectors sharing resources with code that needs to be real time are notoriously difficult to properly set bounds on behavior.
If you aren't doing that then it's not hard real time.
That's... not really a correct description of "hard real time". All system architectures have performance edge cases. The idea of a "hard" real time system is that those be known and fully characterized, and that they can be mapped to equally-fully-characterized application requirements. That way you know all the failure modes ahead of time.
Not all aspects of a real time system need latency control like you're imagining. It's entirely possible to imagine, say, an aircraft autopilot or self-driving system (something that needs ~100ms round-trip latencies to approximate a human pilot) being implemented using a garbage collected runtime, as long as you can guarantee those GC pauses are acceptably small (lots of such systems exist).
The same would be a very hard ask of a piston engine controller, where the timing needs are closer to 100us. Nonetheless the (again to pick an arbitrary example) logging/telemetry subsystem of that engine controller doesn't need that. So as long as you have an OS that can partition the engine tasks from the low priority stuff in a reliable way, you can still imagine a Lisp/Java/.NET/Go/whatever runtime being used there.
Real time is a design philosophy, not a tech stack.
Why would it be hard? If anything a fat runtime makes it easier - see hard-real time JVMs used in military tech.
Hard real time is not too hard in general as it is usually combined with quite low performance-requirements. Boundedness itself is the important property, as opposed to soft-real time which is much more finicky (video games, audio).
Lua gets used on more embedded systems than you might expect, since it's small, fast, and doesn't need floats.
You turn the garbage collector off, tune the allowed step size, and trigger collection in steps when it's allowed. Having the Lua VM and GC around is not the hard part of getting hard real time guarantees out of such a system.
With Lua, those parts get written in C for the most part. With Common Lisp it's possible to use one language for both parts. At least as I'm told, by those who should know, I've not tried writing any CL which wasn't comfortably high level.
Deterministic programs are great, but that's not a prerequisite for hard realtime. A hard realtime system only needs to be guaranteed to satisfy a schedule.
The halting problem says that you cannot make this guarantee for ANY sufficiently complex program.
Even a mere 9kloc L4 kernel (of intentionally not-so-dense C-code) took many man years to prove.
EDIT: Has anyone ever offered such a proof for a program that is just 100kloc? What about 1mloc? Do people actually believe that most non-trivial "realtime" programs are provably realtime?
For hard RT you need both the OS and the language runtime to maintain certain constraints, and I am not aware of Lisp implementations satisfying that. Nothing to be concerned about tho, it's a fairly small niche that is not addressed by most of the popular languages today too.
In every paper there comes a line at which I completely lose what they are talking about. If I'm lucky, this happens after the abstract/intro. In this case, this was it: "A real-time symbolic processing system on a single processor should have the following four features". What?
Thank you. Side note: who thinks it's a great idea not to put any publication date on a paper? And is there a rule for HN to put at least the year in the title, especially if it's not clearly visible at the top of the linked paper. There oughta be.
I love lisp and I currently use SBCL now that CCL is fading away, but I'm a bit skeptical of your claim. Can you provide sources to back that up?
(This is aside from the assertion that "faster than language x" is not the same as "adheres to hard realtime constraints" which is what the overall topic is about.)
[+] [-] willis936|3 years ago|reply
If you aren't doing that then it's not hard real time.
[+] [-] ajross|3 years ago|reply
Not all aspects of a real time system need latency control like you're imagining. It's entirely possible to imagine, say, an aircraft autopilot or self-driving system (something that needs ~100ms round-trip latencies to approximate a human pilot) being implemented using a garbage collected runtime, as long as you can guarantee those GC pauses are acceptably small (lots of such systems exist).
The same would be a very hard ask of a piston engine controller, where the timing needs are closer to 100us. Nonetheless the (again to pick an arbitrary example) logging/telemetry subsystem of that engine controller doesn't need that. So as long as you have an OS that can partition the engine tasks from the low priority stuff in a reliable way, you can still imagine a Lisp/Java/.NET/Go/whatever runtime being used there.
Real time is a design philosophy, not a tech stack.
[+] [-] kaba0|3 years ago|reply
Hard real time is not too hard in general as it is usually combined with quite low performance-requirements. Boundedness itself is the important property, as opposed to soft-real time which is much more finicky (video games, audio).
[+] [-] samatman|3 years ago|reply
You turn the garbage collector off, tune the allowed step size, and trigger collection in steps when it's allowed. Having the Lua VM and GC around is not the hard part of getting hard real time guarantees out of such a system.
With Lua, those parts get written in C for the most part. With Common Lisp it's possible to use one language for both parts. At least as I'm told, by those who should know, I've not tried writing any CL which wasn't comfortably high level.
[+] [-] lisper|3 years ago|reply
Actually it's trivial: just put a bound on the amount of available memory and do a worst-case analysis to GC it all.
The hard part is not engineering the system to have a bound, it is engineering the system so that the bound is reasonable for practical use.
[+] [-] OliverM|3 years ago|reply
[+] [-] naasking|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] hajile|3 years ago|reply
Even a mere 9kloc L4 kernel (of intentionally not-so-dense C-code) took many man years to prove.
EDIT: Has anyone ever offered such a proof for a program that is just 100kloc? What about 1mloc? Do people actually believe that most non-trivial "realtime" programs are provably realtime?
[+] [-] freilanzer|3 years ago|reply
[+] [-] Keyframe|3 years ago|reply
[+] [-] varjag|3 years ago|reply
(Doing soft-RT work in Common Lisp though)
[+] [-] rurban|3 years ago|reply
[+] [-] user3939382|3 years ago|reply
[+] [-] whage|3 years ago|reply
[+] [-] singlow|3 years ago|reply
symbolic processing - symbolic expressions (s-expressions) being the building blocks of lisp programs
single processor - not considering multitasking or multiprocessor concerns
[+] [-] srcreigh|3 years ago|reply
[+] [-] auggierose|3 years ago|reply
[+] [-] mhdhn|3 years ago|reply
[+] [-] czbond|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] gibsonf1|3 years ago|reply
[+] [-] LordGrey|3 years ago|reply
(This is aside from the assertion that "faster than language x" is not the same as "adheres to hard realtime constraints" which is what the overall topic is about.)