Комментарии 36
Охеренно полезная, бл.., статья. Написание real-time софта на десктопной ОС. Автор, тебе не кажется, что тут что-то не сходится? Каким е… ым ху… ты собрался решать задачи, требующие отклика в реальном времени, с неким максимально допустимым временем реакции (например, не больше 10 мс) на, твою мать, non real-time ОС, да еще и в среде, предназначенной для быстрой, твою мать, разработки приложений?! Как ты, бл.., будешь обеспечивать гарантированное к х… м собачьим время реакции, если у тебя:
А потом бл… люди ох… т, а с х… ли это, бл.., у меня, бл.., е… й котел отопления ни… не греет? А это пидарас-разработчик решил, что не… заморачиваться со всякими е… ми ОС реального времени, понапридумывали, бл.., ху..-то всякой, нет бы, бл… ь, все отнять и поделить, бл… ь! Возьму-ка я лучше винду, а ху… и, б..? Да набыдлокожу прогу на шарпе, он же такой простой, специально, бл..., для быдла вроде меня!
Еще, бл… ь, и Java Real-Time System к какому-то х… приплел. Ты посмотри на ее системные требования. Видишь, что написано, специально, бл..., для идиотов:в голове в жопе по этому поводу не свербит?!
Вот же быдло, бл...!
- ОС, которая ни… не предназначена для таких задач,
- Среда, которая н… я не предназначена для таких задач,
- Маленький, как какашка кролика, мозг, который ни… не предназначен для решения вообще каких-бы то ни было задач?!
А потом бл… люди ох… т, а с х… ли это, бл.., у меня, бл.., е… й котел отопления ни… не греет? А это пидарас-разработчик решил, что не… заморачиваться со всякими е… ми ОС реального времени, понапридумывали, бл.., ху..-то всякой, нет бы, бл… ь, все отнять и поделить, бл… ь! Возьму-ка я лучше винду, а ху… и, б..? Да набыдлокожу прогу на шарпе, он же такой простой, специально, бл..., для быдла вроде меня!
Еще, бл… ь, и Java Real-Time System к какому-то х… приплел. Ты посмотри на ее системные требования. Видишь, что написано, специально, бл..., для идиотов:
Real-Time OS. Неужели у тебя ничего
Вот же быдло, бл...!
вы, уважаемый, статью-то хоть дочитали до конца?
Ага, дочитал. Цитирую:
При реализации управления внешними устройствами от ПК при помощи управляемого кода .net фреймворка время реакции будет не меньше чем 1-2мс. Частично снизить влияние параллельных процессов возможно увеличением приоритета потока. При этом не следует забывать о других процессах и при возможности вручную переключать контекст (Thread.Sleep(0)) на другие ожидающие потоки. Следует избегать лишних вызовов сборщика мусора (GC) рациональной работой с объектами, использовать правильную архитектуру приложения, это можно проследить профайлером или системными счетчиками производительности. Также в многопроцессорной системе можно закреплять разные потоки за разными процессорами(см. SetThreadAffinityMask()).
Автор, его волки, на полном серьезе предлагает в приложении, управляющем некими промышленными процессами, шаманить, блядь, с работой с памятью, чтобы, бл.ь, сборщик мусора сидел тихонько и не рыпался! Охеренно. Не, серьезно, охеренный подход.
На кой, спрашивается, хер, надо разумно выбирать инструмент для решения задачи? А давайте, блядь, просто нахерачим все на шарпе, а чтобы оно хоть как-то работало с реальным временем, давайте, блядь, не будем ничего больше на машине запускать, чтобы никто не жрал наше процессорное время, давайте, шаманить с GC… С таким-то подходом потом мосты и рушатся, б… ь.
При реализации управления внешними устройствами от ПК при помощи управляемого кода .net фреймворка время реакции будет не меньше чем 1-2мс. Частично снизить влияние параллельных процессов возможно увеличением приоритета потока. При этом не следует забывать о других процессах и при возможности вручную переключать контекст (Thread.Sleep(0)) на другие ожидающие потоки. Следует избегать лишних вызовов сборщика мусора (GC) рациональной работой с объектами, использовать правильную архитектуру приложения, это можно проследить профайлером или системными счетчиками производительности. Также в многопроцессорной системе можно закреплять разные потоки за разными процессорами(см. SetThreadAffinityMask()).
Автор, его волки, на полном серьезе предлагает в приложении, управляющем некими промышленными процессами, шаманить, блядь, с работой с памятью, чтобы, бл.ь, сборщик мусора сидел тихонько и не рыпался! Охеренно. Не, серьезно, охеренный подход.
На кой, спрашивается, хер, надо разумно выбирать инструмент для решения задачи? А давайте, блядь, просто нахерачим все на шарпе, а чтобы оно хоть как-то работало с реальным временем, давайте, блядь, не будем ничего больше на машине запускать, чтобы никто не жрал наше процессорное время, давайте, шаманить с GC… С таким-то подходом потом мосты и рушатся, б… ь.
Вы как-то слишком категоричны. Никто не мешает портировать .NET Micro Framework на RTOS. Да, это не сделала пока Micorosft, но она и не обещала. А вообще она очень даже за это дело: blogs.msdn.com/b/netmfteam/archive/2009/04/17/net-micro-framework-on-top-of-another-os.aspx
Вы как-то косноязычны больно. Разговаривать нормально умеете?
>> Ты посмотри на ее системные требования
А вы знаете, что сейчас есть Windows CE 6.0 — Real-Time OS, а еще есть .NET Compact Framework, который на ней работает.
Логично предположить развитие этого фреймворка в сторону поддержки Real-Time.
А вы знаете, что сейчас есть Windows CE 6.0 — Real-Time OS, а еще есть .NET Compact Framework, который на ней работает.
Логично предположить развитие этого фреймворка в сторону поддержки Real-Time.
bye!
а зачем столько матов?
Есть же microsof robotics, там вроде как в реальном времени все происходит.
да ну не может реалтайм-обработка проиходить на не-realtime операционных системах.
не может.
никак.
она может быть «очень быстрой», она может быть «быстрой в среднем» или «быстрой как правило», но она не может быть «быстрой всегда гарантированно». именно последнее и есть realtime.
не может.
никак.
она может быть «очень быстрой», она может быть «быстрой в среднем» или «быстрой как правило», но она не может быть «быстрой всегда гарантированно». именно последнее и есть realtime.
а уж полный ппц это использовать для realtime-задач язык с неотключаемым GC «авось я не насоздавал много объектов и мне повезёт»
>>да ну не может реалтайм-обработка проиходить на не-realtime операционных системах.
а я такого и не говорил. Я ответил на это:
«Хотелось бы увидеть через N лет .NET RT по примеру Java Real-Time System»
на Microsoft Robotics Developer Studio вы пишите свой код, потом компилите его и заливаете на устройство. там естественно никаких ОС нет. Скажем это был робот, у него есть датчики удар, препятствии и т.д. Каждый из этих датчиков в реальном времени могут выдать сигнал. Ваш код все это обрабатывает так же в реальном времени.
а я такого и не говорил. Я ответил на это:
«Хотелось бы увидеть через N лет .NET RT по примеру Java Real-Time System»
на Microsoft Robotics Developer Studio вы пишите свой код, потом компилите его и заливаете на устройство. там естественно никаких ОС нет. Скажем это был робот, у него есть датчики удар, препятствии и т.д. Каждый из этих датчиков в реальном времени могут выдать сигнал. Ваш код все это обрабатывает так же в реальном времени.
цитата описания Microsoft Robotics Developer Studio:
RDS generates programs that run on Windows. If your robot has an embedded PC running Windows, like the Pioneer 3DX, then RDS can run directly on the robot. [...]
If a robot has a processor that cannot run Windows, then you need to run RDS on a PC and control the robot remotely.
Робот управляется программой, скомпилированной под .NET с использованием библиотеки RDS. Библиотека нужна для обработки асинхронных запросов (например, получить состояние датчика) без создания дополнительных потоков.
Так что, ничего хорошего в этом тоже нет (имею ввиду автоматическую генерацию нативного кода для любой платформы робота).
RDS generates programs that run on Windows. If your robot has an embedded PC running Windows, like the Pioneer 3DX, then RDS can run directly on the robot. [...]
If a robot has a processor that cannot run Windows, then you need to run RDS on a PC and control the robot remotely.
Робот управляется программой, скомпилированной под .NET с использованием библиотеки RDS. Библиотека нужна для обработки асинхронных запросов (например, получить состояние датчика) без создания дополнительных потоков.
Так что, ничего хорошего в этом тоже нет (имею ввиду автоматическую генерацию нативного кода для любой платформы робота).
А про real time GC вы не слыхали, да?
Вот ссылочки специально для неграмотных, но очень упертых:
domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.ecoop07.html
www.cs.wustl.edu/~mdeters/doc/slides/rtgc-history.pdf
А ведь ламеры еще про region analysis наверняка ни хрена не знают.
domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.ecoop07.html
www.cs.wustl.edu/~mdeters/doc/slides/rtgc-history.pdf
А ведь ламеры еще про region analysis наверняка ни хрена не знают.
Microsoft Robotics — система построенная на передачи сообщений. Там проектирование не предусматривает быстроту, однако сам подход — очень быстрый.
Я правильно понял, прочитав вашу статью, что её смысл заключается в том, что если пошаманить с приоритетами, то от .NET можно добиться реакции в 1мс на сферическом процессоре в вакууме, и если мы не попали на офигенную задержку из-за работы GC? Или есть какой-то более глубокий смысл?
Думаю можно добиться и 1мс, всё зависит от целей. Для эксперимента/самоделки можно попробовать. Для реального использования можно рассчитывать на успех с учетом, что время реакции может доходить до 30мс.
Пример: написать код для обмена данными между программой и внешним устройством. Используем unsafe код в отдельном потоке, GC не вмешивается.
Реальное использование — загрузчик-программатор PIC микроконтроллеров.
p.s. на тему подтолкнула статья «C# for Real-time» bit.ly/9zj807
Пример: написать код для обмена данными между программой и внешним устройством. Используем unsafe код в отдельном потоке, GC не вмешивается.
Реальное использование — загрузчик-программатор PIC микроконтроллеров.
p.s. на тему подтолкнула статья «C# for Real-time» bit.ly/9zj807
Для реального использования можно рассчитывать на успех с учетом, что время реакции может доходить до 30мс.
С редкими провалами на несколько секунд, из-за работы GC или внутренних дел Windows.
Используем unsafe код в отдельном потоке, GC не вмешивается.
Зачем вам .NET в таком случае? Все подобные задачи решаются использованием отдельной библиотеки на unmanaged-коде. Будет гораздо быстрее, надёжнее и эффективнее.
С редкими провалами на несколько секунд, из-за работы GC или внутренних дел Windows.
Используем unsafe код в отдельном потоке, GC не вмешивается.
Зачем вам .NET в таком случае? Все подобные задачи решаются использованием отдельной библиотеки на unmanaged-коде. Будет гораздо быстрее, надёжнее и эффективнее.
Согласен, .NET для критичных задач не нужен, тогда и библиотека не нужна, а нужен весь проект на unmanaged-коде.
А что если бОльшая часть написана под .net? По-моему отдельную библиотеку использовать менее удобно, чем написать отдельную функцию с некоторыми ограничениями.
А что если бОльшая часть написана под .net? По-моему отдельную библиотеку использовать менее удобно, чем написать отдельную функцию с некоторыми ограничениями.
Всю морда и красивые графики можно рисовать и на .NET, а именно саму критичную по времени работу с железяками нужно выносить в unmanaged. Это правильное поведение, при этом не такое уж и сложное, с учётом того, что с железяками .NET работать не умеет и будет идти всё равно через какой-нить враппер, дающий тормоза.
За место Thread.Sleep(0) обычно оптимальнее использовать Thread.Sleep(1), что позволит принудительно положить ваш поток в очередь и дать другим вне зависимости от приоритета поработать. Да и ещё если уж очень не хочется вызывать GC, то это делается предварительным выделением памяти и на время работы уже использовать только стек, или анменедж со стек аллок. Ну или подготовить такие структуры, чтобы они все легли в LOH, где сборка мусора будет очень редкая.
Thread.Sleep(0) тоже «кладет поток в очередь и даёт другим поработать».
При Thread.Sleep(1) последовательность действий будет такой:
1. Говорим планировщику «я сейчас пока работать не буду — запускай другой поток».
2. Планировщик запускает другой поток.
3. Ждем 1 мс. В это время работает другой поток(или несколько, если планировщик решил запустить следующие)
4. Говорим планировщику «поставь меня в очередь, я хочу работать».
5. Планировщик ставит нас в очередь (а поскольку у нас очень высокий приоритет — ставит следующими, а не в конец).
6. Через какое-то время, когда планировщик решит остановить текущий поток- происходит переключение на нас.
При Thread.Sleep(0) происходит всё тоже самое, кроме части «ждём 1 мс». Т.е. скорее какой-то другой поток будет запущен, но скорее всего, только один и на очень короткое время.
При Thread.Sleep(1) последовательность действий будет такой:
1. Говорим планировщику «я сейчас пока работать не буду — запускай другой поток».
2. Планировщик запускает другой поток.
3. Ждем 1 мс. В это время работает другой поток(или несколько, если планировщик решил запустить следующие)
4. Говорим планировщику «поставь меня в очередь, я хочу работать».
5. Планировщик ставит нас в очередь (а поскольку у нас очень высокий приоритет — ставит следующими, а не в конец).
6. Через какое-то время, когда планировщик решит остановить текущий поток- происходит переключение на нас.
При Thread.Sleep(0) происходит всё тоже самое, кроме части «ждём 1 мс». Т.е. скорее какой-то другой поток будет запущен, но скорее всего, только один и на очень короткое время.
Различие будет на шагах 3,4,5, а не только на 3
Очевидная разница про Thread.Sleep(0) и Thread.Sleep(1) это то, что первый откажется от остатка своего кванта и отдаст его готовому на исполнение потоку с таким же приоритетом, при этом сам поток не будет убран из очереди, и если не будет других потоков, то первый поток опять получит процессорное время. Нагляно эксперименты с картинками это можно посмотреть здесь. А почитать, какой прирост скорости мы можем получить, если будем использовать Thread.Sleep(1), можно здесь.
Очевидная разница про Thread.Sleep(0) и Thread.Sleep(1) это то, что первый откажется от остатка своего кванта и отдаст его готовому на исполнение потоку с таким же приоритетом, при этом сам поток не будет убран из очереди, и если не будет других потоков, то первый поток опять получит процессорное время. Нагляно эксперименты с картинками это можно посмотреть здесь. А почитать, какой прирост скорости мы можем получить, если будем использовать Thread.Sleep(1), можно здесь.
Ну, в принципе, Вы правы. С двумя нюансами. Во-первых, в приведенной Вами первой ссылке как раз и рассказывается, что даже при Sleep(0) потоки с меньшим приоритетом всё-равно будут иногда запускаться (редко, но будут). А во-вторых, в том-то по-моему и была задача автора топика, чтобы забрать себе побольше тайм-слотов, не давая запускаться всякой мешающей работе чуши.
<...> возможно ли использовать фреймворк для управления промышленными объектами?
В стране, где системы промавтоматики строят на MS Office, возможно и не такое.
Вообще, по-хорошему думать нужно над отказоустойчивостью, управляющие сигналы сгенерировать проще.
Несомненно странная статья. Для RT можно использовать, что-то типа QP.
ожидал увидеть что то типа Custom Mono port на Qnx.
обескуражен.
обескуражен.
Пишу в эпичном треде.
Блин, что только не придумывают, чтоб на асме не кодить :) О времена, о нравы!
Хотелось бы увидеть через N лет .NET RT по примеру Java Real-Time System. А также промышленное применение .NET Micro Framework на ПЛК известных фирм (Siemens, Omron). Но ЗАЧЕМ? Зачем себя искусственно ограничивать решениями одной единственной конторы, весь стек программирования которой заточен только на Windows?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разгоняем .NET