использование C # для приложений реального времени - PullRequest
24 голосов
/ 21 сентября 2010

Можно ли использовать C # для разработки приложения в реальном времени, которое предполагает непрерывный прием данных с веб-камеры и обработку ввода?

Ответы [ 5 ]

34 голосов
/ 21 сентября 2010

Вы не можете использовать какой-либо основной язык сборки мусора для «жестких систем реального времени», так как сборщик мусора иногда останавливает систему, отвечающую в определенное время.Избегание выделения объекта может помочь, однако вам нужен способ доказать , что вы не создаете мусор и сборщик мусора не сработает.

Однако большинство систем «реального времени» этого не делают.на самом деле нужно всегда реагировать в жестких временных рамках, поэтому все сводится к тому, что вы подразумеваете под «реальным временем».

Даже когда части системы должны быть «жесткими в реальном времени», часто другие больших частей системы, таких как пользовательский интерфейс.

(я думаю, что ваше приложение должно быть быстрым, а не «в реальном времени», если 1 кадр теряется каждые 100лет сколько людей погибнет?)

14 голосов
/ 22 сентября 2010

Я использовал C # для создания нескольких высокоскоростных приложений машинного зрения в режиме реального времени, которые работают круглосуточно и работают в зависимости от приложения. Если в программном обеспечении что-то идет не так, то в реальном мире что-то сразу и явно идет не так.

Я обнаружил, что C # / .Net предоставляют довольно хорошую функциональность для этого. Как уже говорили другие, определенно оставайтесь на вершине сбора мусора. Разбейте обработку на несколько логических шагов, и у каждого из них будут отдельные потоки. Я обнаружил, что модель программирования Producer Consumer хорошо подходит для этого, возможно, ConcurrentQueue для начинающих.

Вы можете начать с чего-то вроде:

  • Поток 1 захватывает изображение с камеры, преобразует его в некоторый формат и помещает в ImageQueue
  • Поток 2 использует ImageQueue, обрабатывает изображение и создает объект данных, который помещается в ProcessedQueue
  • Поток 3 использует ProcessedQueue и делает что-то интересное с результатами.

Если поток 2 занимает слишком много времени, потоки 1 и 3 все еще продолжаются. Если у вас многоядерный процессор, вы будете использовать больше математики. Вы также можете использовать несколько потоков вместо любого, который я написал выше, хотя вам придется позаботиться о том, чтобы упорядочить результаты вручную.

Редактировать

Прочитав ответы других людей, вы, вероятно, могли бы поспорить с моим определением «в реальном времени». В моем случае компьютер производит цели, которые он посылает контроллерам движения, которые выполняют фактическое движение в реальном времени. Контроллеры движения предоставляют свои собственные уровни безопасности для таких вещей, как время, максимальный / минимальный диапазоны, плавное ускорение / замедление и датчики безопасности. Эти контроллеры считывают датчики по всей фабрике с временем цикла менее 1 мс.

8 голосов
/ 21 сентября 2010

Абсолютно.Ключ будет заключаться в том, чтобы максимально избежать сбора мусора и управления памятью.Старайтесь по возможности избегать новых объектов, используя буферы или пулы объектов, когда это возможно.

4 голосов
/ 21 сентября 2010
  • Конечно, кто-то даже разработал библиотеку для этого: AForge.NET
  • Как и в любом приложении реального времени, а не только в C #, вам придется управлять буферами так, как предложил @David.
  • Мало того, есть также XNA Framework (для таких вещей, как 3D-игры), и вы также можете программировать DirectX с использованием C #, которые работают в режиме реального времени.
  • А знаете ли вы, что, если хотите, вы также можете манипулировать указателями в C # ?
1 голос
/ 21 сентября 2010

Это зависит от того, насколько «в реальном времени» это должно быть;то есть, каковы ваши временные ограничения и как быстро вам нужно «что-то делать».

Если вы можете обрабатывать «что-то делать», может быть, каждые 300 мс или около того в .NET, скажем, по событию таймерамы нашли, что Windows работает нормально.Обратите внимание, что это то, что я нашел верным на нескольких системах разного возраста и разной скорости.Как всегда, YMMV.

Но это число ужасно велико для многих приложений.Возможно, не для вас.

Проведите исследование, убедитесь, что ваше приложение реагирует достаточно быстро для вашего приложения.

...