Is C# good for real-time applications?

[Marker Parts]

We have a current assignment to develop a program that is either in C, C++, or C# (the professors and sponsors want to see a system done in C#)

The software must read measurements that will fluctuate such as

• Tank pressures
• Temperatures of liquids
• Know which valves are open/closed.

The program will collect the data real-time (possible 1-5sec delay between sending commands) and send the information over Ethernet or 1553.

Would C# be able to handle such a task?

[OReubens]

Short general answer: No.

Longer answer:
C# or any languare running on a 'closed VM' or any language with a garbage collector (GC) you have no control over (and C# has both) typically isn't suited for "hard" realtime problems because there is no way you can give guarantees about responsiveness with the GC deciding to take whatever time it needs, whenever it feels like it needs to.
Also, being C# you loose performance over native C/C++, despite what some C# fans will want to make you believe. C# comes close for some things, but lags behind massively in other places.

That said, it depends on your timing requirements and the machine it will run on.
However you failed to indicate how soon after the command has been sent over ethernet/1553 a response is required to be available. And that is an important factor too.

C# is typically going to mean desktop PC's which run at GHz speeds and your description seems to indicate an action only happens 1sec apart at fastest and there isn't a critical followup, then I wouldn't even call this 'real time'. You could write this in cobol for an AS400, with an AS400 being emulated in a VM that runs on your PC from 10 years ago and still process it fast enough.



'real time' tends to be about very tight requirements. Either in handling data that comes in at a high rate or in handling rarely occuring triggers extremely fast (or both).

Consider a machine that scans bottles in a bottling plant and needs to pick out the rejects to send them onto a sidetrack of the conveyor belt and it needs to do that for hundreds/thousands of bottles per second and it needs to provide an answer fast enough or the bottle will have passed the reject path.

And often it's about handling those requirements on the cheapest possible hardware because other requirements in the device/system prevent bigger/faster CPU's. So maybe you only have a 10Mhz chip and need to handle stuff within a very limited amount of clockcycles.


THe real question however. Why even go C# when there's (almost?) no self-respecting company working on real-time problems that would even consider using C# for real life purposes. Why do they want to see a system don in C# ? just for the heck of it or because they have a real life use for it being that way. If just for the heck of it, it makes you wonder what they'll actually end up teaching you or giving you as an extra bonus on your first job interview. So there you are, sitting in an interview with RealTime Solutions Inc, and they ask if you have experience. "oh yes, I made a real time system in school". Interesting tell us more about it. "well I wrote it in C# and...". "Ok, thanks for your time. NEXT!" (ok, they'll prob won't be that callous, but it won't help).

[ahoodin]

We have a current assignment to develop a program that is either in C, C++, or C# (the professors and sponsors want to see a system done in C#)

Everything OReubens says is absolutely correct, however you could use C# to write a part of the system that is not time critical, like just a UI for the realtime system as a whole. It would just display values and allow some input from the user in this role. In some roles fast is close enough to realtime.

[Marker Parts]

Thank you for your reply. The sponsors would like to see an immediate response from the command over Ethernet or 1553. Something else I didn't explain is that they have a filtration system at one location, but can send commands from a neighboring city or from another plant in another state. From their description commands & responses seem to occur instantly onsite, but their is a delay when commands come into the facility. Their estimation was 1-5 secs depending on the command.

Once again thank you for your time. I will suggest to my team we develop the code in C/C++.

[OReubens]

What you really need to do is asses the actual real time constraints. How fast do you need to respont to a trigger, and how often do triggers arrive and what is the latency in the arrival and response.

based on that you can calculate how much time you have per trigger, then based on estimated hardware (or maybe you have control over what hardware will need to be purchased/used) you can make educated guesses. As you get more experienced at this, you'll be better at making those educated guesses. For now, take your assumptions and overcompensate.

As I said before, if you only need to process something once every 1 Second, and response times aren't super critical, and you have a semi decent machine to run this on, then C# will be plenty fast.

[Arjay]

Your bottleneck probably won't be the language (c# vs c++) but other factors such as network latency and so on. In other words, you need to receive the data to process, but once you have, C# can process it fine.