|
I am looking for a job and I often come across "Real time experience needed", What does a real time application from a c# prospective entail? Arent we just talking about multithreading? if not is there a difference between multithreading and real time? is this stuff hard to master if you have not done multithreading? thanks for your time |
|||||
|
|
"Real Time" has a well defined meaning in software engineering. One that has little to do with the job advertisement you saw. Real time is critical in control systems, you promise a hard upper limit on how quickly your program responds to an input event. The canonical example is the flight software for a rocket. When it veers off course, you better have an upper limit on how quickly you adjust the nozzle. Being occasionally a bit late doing this is not good enough, the code stops running when the cpu is vaporized in a spectacular half a billion dollar fire ball. Which is the true engineering challenge, being on time every time is the hard problem to solve. A soft real-time system is on-time 99.9% of the time. Getting rid of the 0.1% rocket destruction mode requires a different kind of execution environment. Windows is often quoted as a non-real time operating system. Which isn't true, it is only non-real time in user mode. It has excellent response times to interrupts in kernel mode, assuming you can avoid getting a crappy audio driver installed. Kernel mode is however off limits for the friendly kind of execution environments such as provided by the CLR. And bugs in your code beget a blue screen. The financial industry has a different definition of real time. More in line with the literal meaning: at least as fast as the stock broker's perception of time. The canonical example of a need for this is program trading. Software that listens to the stock ticker and makes very short term buy and sell decisions. The angle is that they take advantage of the changes in prices of financial paper. Intuitively: if the price of a stock is going up then buying the stock early and selling it an hour later gives you a profit. Money for nothing. Works the other way too, sell early when the price is falling, buy back later. Traditionally done by humans. You've probably seen the scene, a large office with hundreds of people, each with a dozen monitors crammed in front of them. Staring at the stock tickers and trying to guess which way it is going. The edge is that you make the trading decision just a bit quicker than everybody else that is looking at the same data. The faster you respond, the more pennies you skim off my retirement account. To be competitive with the army of brokers looking at these screens you have to at least operate real time, coming up with the trading decision faster than the humans. Taking longer than 'real time' is completely useless. You'd make trading decisions on stale data, stale by the amount of time you need to process the data. You'll be the one that everybody else makes a penny off. What matters little though is being late only 0.1% of the time. Yes, you'll typically induce a loss but it is a small one compared to the 99.9% of the time that you're faster. Or fast enough. As such, running your code on a non-real time operating system and in a VM with garbage collection isn't a problem. In fact, it is an advantage because software that ships sooner cost less to develop and makes money being in use before the competition's version comes online. The real challenge in making this kind of code competitive with everybody else is being able to eke good decisions out of a mountain of data. That's where threading becomes important. You'll have to process the stock ticker data as soon as it comes in. That requires a thread. And detect significant changes, before everybody else does. That requires taking advantage of all multi-core cpu resources, done with threads. |
|||||
|
|
Hmm, I'm pretty sure that you're misinterpreting the phrasing of the job application. It's quite impossible to write a real-time application in C#. Windows is not a real-time operating system for starters, so that'll cripple any good intentions that you have. But then on top of that, the .NET Framework is a managed code environment, definitely not the place to start if you absolutely need a real-time application. There are plenty of benefits to managed code, but at this point, raw unimpeded speed is not one of them. I assume what they're asking for is someone with real-world experience writing C# applications. It doesn't describe the type of programs that they've written (real-time, multithreaded, etc.), but rather the type of experience that that person has writing programs. They don't want someone who has written an alarm clock and a notepad program in C# for their own personal use. They want someone who has experience writing real-world applications that are used in production environments by a number of different people. C# is simply not intended for real-time computing. If that's really what they're looking for, that's not the job that you want. They don't understand what they're asking for, and chances are, it'll be an uphill battle convincing them of anything different. |
|||||||||||||||
|
|
Real-time programs must execute within strict constraints on response time. Say you're processing some sensor's data and your program should be garanteed to take some action (e.g. shutdown a reactor :]) within a limited timeframe after receiving next chunk of data. So it's not "just multithreading". If we are talking about C#, there are a lot of things that might hamper such a behaviour. (For example, GC. And the OS itself) To be honest, I'm not sure if it's possible at all to make a real-time application running a non-realtime OS and using a managed environment... Hope this helps. |
|||||||
|
