22 Jul
2020
22 Jul
'20
5:13 a.m.
On Mon, Jul 20, 2020 at 06:04:11PM -0700, Larry McVoy wrote:
On Mon, Jul 20, 2020 at 05:11:48PM -0500, Ed Carp
wrote:
Never fear, Victor's work got published in a number of Linux
conference, so it wasn't totally buried.
On 7/20/20, Larry McVoy <lm(a)mcvoy.com>
wrote:
So many people get this wrong, they want to make "real time" in Unix
"good
enough" and it messes with everything. Victor's idea was awesome.
And you know what sucks? I was on the Usenix review committee and I gave
it 2 thumbs up but someone else, looking at you, Rob, said it was not
interesting because the real time kernel wasn't POSIX. Even though the
real time kernel had pipes, signals, and shared memory with Linux.
He was a bigger deal than me so it didn't get published.
I love the Rob in question, not Pike, but this was one of the most bone
headed calls I've ever seen him make. The world needed to see this. Clem should pay attention, in my opinion, this is
how you do Unix and
real time. Because Unix is time sharing and throughput, that is the
opposite of what real time is. Wedging real time into Unix is a mistake.
Agreed. Wind River bought it and buried it because it competed
with their stuff
that was nowhere near as good.
I can't get into the mind of Wind River. but having worked on a
commercial real-time extension to Linux, and having gotten a IBM
Systems Journal publication[1] out of it, I have a slightly different
perspective.
[1] https://ieeexplore.ieee.org/document/5386551
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.
This is even worse if you are working in a military application, since
small population of "can program real-time programmers" is further
reduced by "can get a security clearance".
Fortunately, with modern, fast CPU's, it's possible to do real-time
via brute force, and as it turns out, there are a very large number ofJ
real-time tasks which can deal with real-time latency that are tens of
milliseconds, at which point you even use real-time Java with a
real-time garbage collector running on a real-time Linux. And that's
what Raytheon and the US Navy chose to use on their Zumwalt Class
destroyers, and that's how I and my team got the IBM Systems Journal
publication. :-)
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.
Cheers,
- Ted