RTOS (VXworks)에 일반적으로 사용되는 디자인 패턴

Question

RTOS에 일반적으로 사용되는 디자인 패턴에 대해 도움을 줄 수 있습니까?
VXworks에서 어떤 패턴이 더 바람직합니까?

Answer 1

질문에서 두 번째 문장을 무시할 수 있습니까? 그것은 의미가 없으며 아마도 디자인 패턴에 대한 오해를 지적합니다. 그러나 첫 번째 부분은 흥미 롭습니다. 즉, RTOS가 아닌 실시간 시스템을 처리하도록 일반화했습니다.

가장 익숙한 패턴은 기계 론적이지만 많은 경우 실시간 시스템에서는 상위 수준의 아키텍처 패턴도 중요합니다.

는 아마도 실시간 시스템 패턴의 주된 저자 일 것입니다. 피사체에 대해 말하고 싶은 것을 맛보고 싶다면 this article을 Embedded.com (세 번째 시리즈의 세 번째 부분입니다. 첫 번째 두 개는 물론 피사체를 터치하기 때문에 반드시 읽으십시오. (1)(2))). 또한 Embedded.com을 방문하여 검색 상자에 "디자인 패턴"을 입력하는 것보다 최악의 상황을 피할 수 있습니다. 주제에 대한 특정 패턴과 일반적인 기사에 대한 기사가 많이 있습니다.

"RTOS (VxWorks)"에 대한 패턴을 요청할 때 구체적으로 생각하고있는 동안 VxWorks에서 특별히 사용한 패턴은 Facade 및 Adapter 패턴입니다. 부분적으로 객체 지향 API를 제공하고, 또한 RTOS 불가지론 추상화 수준을 제공합니다. 그 결과 생성 된 클래스는 Segger emBOS (작고 저렴한 비용의 로열티없는 RTOS를 실행할 수 있도록), Windows 및 Linux 모두를 위해 구현되어보다 강력한 도구로 더욱 풍부한 환경에서 코드의 테스트, 디버그 및 시뮬레이션을 가능하게합니다.

많은 패턴의 비 한정적인 목록이 Wikipedia에 제공되며 그 중 다수는 실시간 시스템에 적용될 수 있습니다. 나열된 동시성 패턴은 가장 명백하게 관련이 있습니다.

Answer 2

Mike DeSimone이 언급 한 것처럼 너무 일반적입니다. 그러나 여기에 RTOS (VxWorks뿐 아니라)를 염두에 두어야 할 몇 가지 사항이 있습니다.

1. ISR에서 너무 많이하지 마십시오. 가능한 경우 대기중인 작업으로 일부 처리를 전달합니다.
2. 멀티 스레딩을 최적으로 유지하십시오. 너무 많으면 컨텍스트 스위칭 오버 헤드가 발생합니다. 너무 적 으면 문제 해결 방법이 복잡해질 수 있습니다.

Answer 3

또 다른 중요한 측면은 RTOS를 예측 가능하고 사용자가 이해할 수있게 유지하는 것입니다. 일반적으로 공정하거나 적응하려고 시도하지 않는 고정 된 우선 순위 스케줄러를 보지만 오히려 말한대로 정확히 수행하고 우선 순위가 엉망이되어 작업을 굶기면 그렇게하십시오. 커널 작업을 완료하는 데 필요한 시간은 짧고 예측 가능하며 종종 최악의 실행 시간으로 문서화됩니다.