22 Jul
2020
22 Jul
'20
7:40 a.m.
On Jul 21, 2020, at 8:13 PM, tytso(a)mit.edu wrote:
The issue is that there aren't that many good real-time programmers
Tavailable. Furthermore, many real-time applications need to do a lot
more than data acquisition, so having access to POSIX API's in the
real time task is very attractive. Sure, you can try to interchange
information between the real-time task and the POSIX task, but that's
a lot more complicated, and that's where the "not enough real-time
programmers" rears its head again.
...
Sure, there will be some number of real-time task which needs
single-digit millisecond real-time guarantees --- in which case you
can write it in C using Real-time Linux. And for those really cases
where you need latencies which are in the tens of microsecnds; then
yeah, at that point you might need specialized OS's. But the cases
where you need fast, hard real-time is pretty rare compared to those
cases where real-time Java is sufficient.
The approach taken by Massalin in their Synthesis Kernel seemed quite
promising. By using runtime code synthesis they were able to run realtime
music synthesis at 25Khz sampling rate on a 20Mhz 68K machine. Too bad
these ideas didn't take off. I wanted to use similar ideas in lieu of
code like netgraph (in FreeBSD) or N layers of networking code but no
tools existed. Today, on a computing device your browser may freeze
for a few seconds due to garbage collection or whatever.
Seems to me, a bigger issue than not-enough-real-time-real-programmers
is a lack of good real time programming abstractions and tools. No way
to specify or test a timing budget or required maximum latency. There
are things like CBQ (class based queueing) for managing traffci flows
but no such general purpose support for mapping code to hardware to
meet timing and latency requirements.