4 ms·
I assume it means the user input handler is given a deterministic time slot to do stuff. Regardless of what the operating system is doing, it will always schedu
by joshvm 6y ago
I assume it means the user input handler is given a deterministic time slot to do stuff. Regardless of what the operating system is doing, it will always schedule mouse movement (or something along those lines). It's a software implementation (scheduling), but it requires hardware that can support it - usually you need fine-grain control over interrupts. So typically nowadays you see RTOSes on microcontrollers (eg ARM). Maybe more precisely you need access to that fine grain control and that often means getting hold of datasheets that are under strict NDA (eg Broadcom).
RTOSes are often found in autopilot and vehicle management systems controlling critical peripherals or safety critical software. More mundanely there are also sensors that will get upset if you don't give them undivided attention for fixed periods of time (or if you interrupt them, they will terminate the transfer). Image sensors are particularly picky about this.
- qppo 6y agoYou can implement hard real-time scheduling using polling instead of interrupts, which is usually faster anyway. It just changes how you measure your tolerance, since nothing is instantaneous, ever.
- ChuckNorris89 6y agoThis! Automotive hard real time is polling based.
- qppo 6y agoI think most things are trending that direction, even in soft/non real-time. How fast can an interrupt respond these days anyway, a dozen microseconds?
- ianhowson 6y agoNanoseconds if you can respond inside the interrupt handler ('top half' in Linux.) Microseconds to milliseconds with significant variability if you need to be scheduled ('bottom half'.)
- jacquesm 6y agoAnd that only if your codepath is deterministic. Linux can do pretty funny stuff at times. I've run a plasma cutter under Linux on a run-of-the-mill VIA SBC, it was actually pretty easy: just make a program setuid root, use that to disable interrupts after you've read all your data in and then just go wild on polled and precision timed IO until you're done. Re-enable interrupts and return as if nothing ever happened.
- joshvm 6y agoYep, more that actually being able to turn interrupts off is a barrier to doing real time work on desktop OS's, for example. Even if you can disable them globally (I think on the Pi you can with some low level C), but stuff goes wonky quickly e.g. if the WiFi soc doesn't get serviced. It's a good lesson to play with polling versus interrupts on a micro. Susprising just how many cycles it takes to jump into the ISR.