Non-embedded real-time problems
Any problem with a deadline is a real-time problem. If missing the deadline is so unacceptable that it's not worth talking about recovering from missing a deadline the problem is a hard real-time problem.
Here are some examples from outside the embedded computing world:
- Commuting to work. The system doesn't have good real-time characteristics. Many things can cause unexpected delays from traffic lights to vehicle breakdowns. How early do you need to leave be nearly certain of arriving in time for a meeting? When you think about it, you might be better off walking. It's slower, but the possible delays are more manageable.
- Payroll. The process of collecting data on hours worked, administrative changes and cost accounting, getting them into a computer, running the programs and printing the checks or sending the auto-deposit data to the banks could take a week or more, but the checks had better be there on time. I once worked for a computer service bureau, and there were some tense situations when the payroll was delivered just a few minutes late.
- Parenthood is rich with deadlines from cooking to carpooling. If I really thought about the multi-threaded/multi-processor system with complex resource contention that my wife and I face each day as a real-time system I'd probably declare it intractable and give up. :-)
- Playing any instrument is probably a real-time problem, but I understand stringed instruments best. Each note has to be played within a few milliseconds of the right moment. When I'm playing an interesting pattern on my bass I have to work out fingering that will let me get to all the notes on time. It's not just speed. Sometimes the fast passages are easy and an easy-sounding bit wants to get my fingers tangled.
- Any sport that involves interacting with a moving ball/puck/shuttlecock.
The above problems are probably not generally hard real-time. Missing the deadlines might be bad, but seldom unrecoverable. But, real-time problems are easier to manage if you treat them as hard real-time. If you can prove that you will meet all deadlines you don't have to think about recovering from missed deadlines. Recovering from missed deadlines can be complicated, messy, embarrassing, and error prone. System design is easier if there's a way to make the probability of a missed deadline low enough that you can ignore miss recovery (or make recovery trivial).
- peterd's blog
- Login or register to post comments
More examples
The night before last the email app on www.me.com "got" me.
I was trying to send an email from my me.com address to my wife's email (also on me.com.) I pressed send and there was a long delay. Then the app told me it could not send the email -- I should try again later. I tried many times, and then went to another email site and sent it from there. The next day, my wife wondered why I sent her the same message so many times. Evidently most, maybe all, the emails I thought had failed were successfully delivered.
So, evidently Apple's dot.me code has a deadline miss handler for email transmission -- good. But, it was seeing false misses -- bad. Thinking about how that could have happened reminded me of a related problem that I don't see much any more.
Sometimes, when I buy something online, the web site tells me to click a button to finalize the transaction and warns me not to click it again or go back. The transaction may take some unspecified long time. When I'm in a bad mood, that warning gets me grumbling about lazy programmers.
First: completing a transaction that involves a credit card is a complicated, distributed, activity, but have they tried to use real-time programming disciplines? Can't they tell me how long I should wait before I know something went wrong?
Second: if they can't give a guarantee, how about a deadline miss handler? Then after a second or two I'd see something that says there was a problem and offers to email me an acknowledgement if I don't want to wait.
Third: if all real-time considerations are out of reach, why don't they make the dangerous actions (pressing buy again) impossible before they submit the transaction.
Last: if all that is impossible, why don't they look for duplicate transactions and eliminate them. That could be done off-line.
And thinking about the dot-me code
Here's the process I imagine going through the dot-me architects' heads.
When the user presses the send button, turn it inactive and wait for a response from the server before going back to the normal email display.
But, what if the server never responds? It will hang the dot-me window, or maybe the whole browser. The user will assume something's broken, probably quit the browser, and probably think nasty things about us.
So put a timeout on waiting for the server. Make it the lesser of the maximum time the server could possibly take and the maximum amount of time we can let the user wait before the browser looks hung. If it takes longer than that, the mail server's got to be down. Tell the user to try again later and release the GUI.
What if the server was slower than we thought and it tells us it did send the email...after we decided it wouldn't?
What can we do? The user might have sent it again, or maybe he gave up and went on to work on something else. If we tried to tell him that we were wrong about failing and we did send the email, how would we even tell the user (simply) which email we're talking about?
But, if what if it does succeed late, and it's a big message, and the user sends it a lot of times? It could fill the recipient's mail box, or make the sender look silly.
Look, the timeout is, like, 15 seconds. We're a client/server application. If the server takes that long it's dead and we've got serious trouble. It isn't going to send the message late.
My imaginary architects just decided the server side code -- at least the mail server part of it -- was a kind of hard real-time application. A late response from it is worse than useless. (Though in this case missing a deadline is survivable. The server could meet its timing requirement by dropping any email that it did not send by its deadline.) That's fine. It might even be the only practical way to design this kind of distributed application. However, they evidently didn't tell the people designing the server that their application had a deadline.
I wonder whether async client/server internet apps (the AJAX family) will push people to write real-time code on the server.