C＃可用于开发实时应用程序，包括连续从网络摄像头获取输入并处理输入吗？
我使用C＃创建了多个实时，高速，机器视觉应用程序，这些应用程序全天候运行，并且具有依赖于应用程序的移动机械。如果软件出现问题，在现实世界中会立即出现问题。
我发现C＃/ .Net提供了非常好的功能。正如其他人所说，绝对是垃圾收集的最佳选择。分解为几个逻辑步骤的处理，并且每个都有单独的线程。我发现生产者消费者编程模型适合这一点，也许ConcurrentQueue为初学者。
您可以从以下内容开始：
如果线程2花费太长时间，则线程1和3仍在继续。如果你有一个多核处理器，你将会在数学上投入更多的硬件。您也可以使用多个线程代替我上面编写的任何线程，尽管您必须手动对结果进行排序。
编辑
在阅读了其他人的答案之后，你可能会认为我对“实时”的定义。在我的情况下，计算机产生目标，它发送给运动控制器，进行实际的实时运动。运动控制器为定时，最大/最小范围，平滑加速/减速和安全传感器等提供自己的安全层。这些控制器读取整个工厂的传感器，循环时间小于1ms。
您不能将任何主流垃圾收集语言用于“硬实时系统”，因为垃圾收集有时会在规定的时间内停止系统响应。避免分配对象可能会有所帮助，但是您需要一种方法来证明您没有创建任何垃圾并且垃圾收集器不会启动。
然而，大多数“实时”系统实际上并不需要总是在一个艰难的时间限制内做出响应，所以这一切都归结为你所说的“实时”。
即使系统的某些部分需要“硬实时”，系统的其他大部分内容（如UI）也不会。
（我认为你的应用程序需要快速而不是“实时”，如果每100年丢失1帧，将会有多少人被杀？）
绝对。关键是尽可能避免垃圾收集和内存管理。尽可能使用缓冲区或对象池尽可能避免使用新对象。
这取决于它需要的“实时”程度;即，你的时间限制是什么，以及你需要多快“做某事”。
如果你可以在.NET中每隔300ms左右处理“做某事”，比如在计时器事件上说，我发现Windows工作正常。请注意，这是我在不同年龄和不同速度的多个系统上发现的事情。一如既往，YMMV。
但对于许多应用来说，这个数字非常长。也许不适合你。
做一些研究，确保您的应用程序对您的应用程序做出足够快速的响应。