Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

Posted Aug 17, 2016 12:20 UTC (Wed) by farnz (subscriber, #17727)
In reply to: Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police) by nye
Parent article: Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

That's not the definition I learnt; there are three grades of "real time" task in the text books I used, distinguished by the effects of missing a wall-clock deadline (note that all three types need real time guarantees from the OS):

Interactive: Interactive tasks are those where the value of the result is inversely proportional to its lateness - animating a progress bar, for example, where the longer it takes per frame, the less useful the progress bar is.
Soft real time: Soft real time tasks are those where the result is worthless after the deadline, but where missing the deadline is a transient failure. An example might be Opus decoding for playback - if I can't complete decoding the sample by the time it's due for playback, then I might as well abort decoding that sample; however, once I start meeting deadlines again, I resume flawless playback.
Hard real time: Hard real time tasks are those where missing the deadline causes a complete failure of the task; e.g. a pacemaker is hard real time, as missing the deadline can render the pacemaker worthless.

In this model, a mobile or desktop OS benefits from being soft real time, but does not need to be hard real time.

Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

Posted Aug 17, 2016 13:58 UTC (Wed) by bfields (subscriber, #19510) [Link] (2 responses)

"In this model, a mobile or desktop OS benefits from being soft real time, but does not need to be hard real time."

As one counterexample, it's increasing common to use ordinary mobile or desktop OS's to create live music.

So, maybe you have a midi controller keyboard plugged into your ipad, and when you press middle C, the keyboard sends a message to your ipad, and a software synth on your ipad does a bunch of data processing to produce a sound.

If that takes too long (I'm not sure exactly--a few 10's of ms?), then people notice. Nobody dies, but the ipad has failed at the job it's been bought for, and it's a failure that somebody making their living as a performer can't afford with any frequency.

Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

Posted Aug 17, 2016 14:05 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

That doesn't make it hard real time - in both soft and hard real time tasks, the failure to meet the deadline is a failure of the task. The distinction is in terms of recovery if you miss some number of deadlines then start meeting deadlines again; in a soft real time task, you fail every time you miss a deadline, but you recover once you start meeting deadlines again. In a hard real time task, missing a deadline means that the task can never recover without external assistance.

So, the situation you've described is soft real time - you've failed by missing the deadline, but once you start meeting deadlines again, the device is useful for the job it was bought for. If it were a hard real time situation, missing the deadline would mean that until you rebooted the ipad, the software synth did not function at all - no sound came out.

Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

Posted Aug 17, 2016 16:07 UTC (Wed) by zlynx (guest, #2285) [Link]

If the goal is to make application responsiveness a priority then I would _make_ it hard real time by crashing the app when it failed to hit the deadline. During app verification I would force it to run under simulated worst case conditions.

In such a situation the app has completely failed by not hitting its timing requirements and it can't recover to be soft real time because it is dead. And I consider this completely reasonable. Maintaining 60 Hz interactive response should be _trivial_ on modern hardware.

It isn't any more artificial a limitation than in robotics. A robot arm that fails to stop in time does not necessarily mean "hard" real time either, since after bashing its way through the target it could just keep going. As long as it reaches _most_ of its timing targets everything is fine right? No, not really, so if that does happen, safety features force the hardware to shut down, which is the same deal.