Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question

migrated from stackoverflow.com May 7 '11 at 21:43

This question came from our site for professional and enthusiast programmers.

    
If you run across it "often", I wonder if it's real-time computing they're talking about or not. In today's world, it might just as well mean "we don't want somebody who can only work with a request/response model"... –  Matti Virkkunen May 7 '11 at 9:27
    
I would like to get into banking and it 's often required.Or shall I just forget it –  Anonymous May 7 '11 at 9:36
add comment

3 Answers 3

"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.

share|improve this answer
1  
@HansPassant Thank you for a very thorough answer.I have never worked in the financial sector and was wondering what all the fuss about "real time" is.I have a better idea now. –  Anonymous May 7 '11 at 18:10
add comment

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.

share|improve this answer
    
@CodyGray.I see what you mean.You answer helped a lot.A least I have an idea what they are talking about.I would like to get into banking and it seems to be a very catchy phrase agencies seems to use eg "C# Developer Multi Threaded Real Time GUI Development" –  Anonymous May 7 '11 at 9:41
    
@user: That's very strange. Do you have a link to any such job posting? Multi-threading has nothing to do with real-time computing. That sounds like something written by an HR department with no input from the technical folks... In short, nonsense. –  Cody Gray May 7 '11 at 9:44
    
@CodyGray jobserve.com/… –  Anonymous May 7 '11 at 9:46
1  
I would have bet money against that job opening being in London. The posting sounds like it was translated 3 or 4 times from the original language it was written in. The very first sentence doesn't make any sense: "This top Investment Bank is looking for a talented Developer with strong C# Development skills multi threaded Real Time GUI with good design patterns unit testing full development life cycle experience." And English doesn't just capitalize random nouns. –  Cody Gray May 7 '11 at 9:48
1  
Actually it makes sense. It could be a market trading applicaion having to update a ui in soft real timee (i.e. semi time critical). I currently work on an app using more than 100 worker threads to manage financial information, and yes, it is possible in C#. not "hard real time" but "soft real time". –  TomTom May 7 '11 at 10:00
show 4 more comments

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.

share|improve this answer
    
You can always set the thread/process priority to realtime which is higher than OS calls and that makes the app execute immediately, but I don't think anyone does that.. That also doesn't resolve the GC issue. C# just isn't right for this job. –  kubal5003 May 7 '11 at 9:39
1  
@kubal: It neither alleviates the problem of garbage collection, the fact that your application is running on top of a managed framework, nor the fact that Windows is simply not a real-time OS. Regardless of what the name they chose might indicate, there is simply no guarantee that such a process will actually run in real time. –  Cody Gray May 7 '11 at 9:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.