"Windows는 실시간 운영 체제가 아닙니다"란 무엇입니까?

지연 시간 모니터링을 수행하는 LatencyMon 이라는 응용 프로그램을 발견했습니다 .

프로세서에 부하가 많을수록 반응 속도가 느리거나 잠재적 인 시스템이된다는 것을 항상 알고 있습니다. 그러나 LatencyMon 페이지의 두 번째 섹션에서 첫 번째 문장은 "Windows는 실시간 운영 체제가 아닙니다 (RTOS)"입니다. 생각이났다 Linux, Unix 또는 Mac OS X와 같은 다른 운영 체제와 다른 점이 있습니까?

"실시간"운영 체제가 있습니까? 아니면 단순히 제품을 구매하도록하는 마케팅 계획입니까?

편집하다:

또한 RTOS의 예가 있습니까?

windows latency real-time

— 채드 해리슨
소스

예를 들어 QNX는 실시간입니다.

— new123456 년

답변:

Wikipedia에는 실제로 놀라운 정보가 많이 있습니다.

RTOS (실시간 운영 체제)는 실시간 응용 프로그램 요청을 처리하기위한 운영 체제 (OS)입니다.

RTOS의 주요 특징은 응용 프로그램 작업을 수락하고 완료하는 데 걸리는 시간과 관련된 일관성 수준입니다. 변동성은 지터입니다. 하드 실시간 운영 체제는 소프트 실시간 운영 체제보다 지터가 적습니다. 주요 설계 목표는 높은 처리량이 아니라 소프트 또는 하드 성능 범주를 보장하는 것입니다. 일반적으로 또는 일반적으로 최종 기한을 충족시킬 수있는 RTOS는 소프트 실시간 OS이지만 최종 기한을 결정적으로 충족 할 수있는 경우 하드 실시간 OS입니다.

RTOS에는 스케줄링을위한 고급 알고리즘이 있습니다. 스케줄러 유연성을 통해 프로세스 우선 순위를보다 광범위하고 컴퓨터 시스템으로 조정할 수 있지만, 실시간 OS는 더 좁은 범위의 응용 프로그램 전용입니다. 실시간 OS의 주요 요소는 최소 인터럽트 대기 시간 및 최소 스레드 전환 대기 시간입니다. 실시간 OS는 주어진 기간 동안 수행 할 수있는 작업량보다 얼마나 빨리 또는 얼마나 예측 가능하게 대응할 수 있는지에 대해 더 중요합니다.

많은 워크로드에서 효율성이 떨어지기 때문에 실제로 운영 체제가 거의없는 것입니다. 현재 주요 소비자 운영 체제 중 어느 것도 실시간이 아닙니다. 불행하게도, 때로는 비 실시간 환경의 것들이 다른 것들을 기다리는 것 주위에 앉아 있어야한다는 것을 의미합니다. 일반적으로 합리적인 시간 내에 무언가를 산출하지 않는 경우에만 문제가됩니다.

현재 가장 널리 알려진 가장 널리 배포 된 실시간 운영 체제는 다음과 같습니다.
LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE
포괄적 인 목록 은 실시간 운영 체제 목록을 참조하십시오 .

— 신라이
소스

실시간 OS는 일반적으로 매우 정확한 시간 내에 의사 결정 / 계산 등을 완료해야하는 매우 정밀한 제어 시스템과 같은 매우 전담 된 역할에 사용됩니다.

— Lamar B

RTOS의 예가 있습니까? 이와 관련하여 질문을 업데이트합니다.

— 채드 해리슨

en.wikipedia.org/wiki/Real-time_operating_system#Examples

— ta.speot.is는

@ ta.speot.가 말한 것-기사에 이미 링크되어 있습니다. 그래도 일부를 편집하겠습니다.

— Shinrai

나는 Wiki 페이지의 맨 아래에 만들지 않았다 ... 죄송합니다 한판 승부 : /

— Chad Harrison

실시간 운영 체제는 종종 지침 또는 시스템 모니터링과 같은 역할을하는 임베디드 시스템에 사용됩니다. 실시간 시스템 (및 비 실시간 시스템과 다른 점)에 대해 기억해야 할 핵심 사항 은 실시간 시스템에서 답변이 늦으면 잘못되었다는 것입니다. Excel에서 일련의 숫자를 추가하여 (작업이 지연되는 경우 실제 영향은 없음) 자동차에서 브레이크를 적용하는 것 (지연이 치명적일 수있는 위치)에 대해 생각하면이 작동 방식을 쉽게 확인할 수 있습니다.

— 스콧 C 윌슨
소스

기본적으로 RTOS는 특정 (일반적으로 낮은) 시간 내에 IRQ (인터럽트 요청) 서비스를 제공 할 수 있습니다. 표준 운영 체제에는 그러한 보증이 없습니다.

대부분의 최신 시스템에서 대부분의 장치는 IRQ를 생성 할 수 있습니다. 이로 인해 CPU가 수행중인 작업을 중지 (중단)하고 인터럽트 서비스 프로그램을 실행합니다. 이 서비스 프로그램은 장치가 필요로하는 모든 것을 수행합니다. 즉, 장치에서 RAM으로 데이터를 가져오고 다음에 수행 할 작업을 장치에 알려줍니다.

x86에서는 CPU에 IRQ 회선이 하나만 있기 때문에 인터럽트를 받으면 CPU가 인터럽트 소스를 인식하고 다시 활성화 할 때까지 추가 인터럽트가 자동으로 비활성화됩니다 (NMI, RESET 및 SMI 제외). 따라서 표준 i386 / amd64 Windows에서 우수한 장치 드라이버는이 상태에서 최소한의 처리 만 수행하므로 인터럽트를 다시 활성화 한 다음 나중에 인터럽트의 완전한 처리를 지연시킬 수 있습니다. 한 번에 코어). 잘 모르겠지만 Linux도 마찬가지입니다. 그럼에도 불구하고 인터럽트가 서비스되는 시간에 대한 확실한 보장은 없습니다.

디스크, 키보드, NIC와 같은 대부분의 PC 장치에서 IRQ 서비스가 약간 지연되는 경우 성능 손실 외에 다른 문제는 발생하지 않습니다. 이것은 오디오 및 비디오 입력과 같은 장치에서 더 많은 문제가 될 수 있습니다. 장치는 아무것도 버퍼링하지 않으며 PC는 들어오는 데이터 스트림을 따라야합니다.

— 로렌스 C
소스

"x86에는 1 개의 IRQ 회선 만 있습니다"라는 의미를 설명 할 수 있습니까? 마지막으로 80186 컴퓨터를 와이어 랩핑했을 때 (수십 년 전), 8259 PIC에는 8 개의 채널이 있고 당시의 공칭 PC에는 두 번째 캐스케이드 연결되어 있으며 총 15 개의 채널이 포함되어 있습니다. NMI?

— Glenn Slayden

x86에는 IRQ 회선이 하나만 있기 때문에 PIC가 필요합니다. 그러나 x86 인터럽트가 비활성화 된 경우 PIC는 CPU가 다시 활성화 할 때까지 기다릴 수 있으며 IIRC는 그렇게합니다. 68000과 같은 IIRC의 다른 CPU는 3 개의 인터럽트 핀을 가지고 있으며 CPU 자체에서 코딩 된 우선 순위 레벨 0-7을 기대했습니다. 지금은 실제로 고려해 보았지만 68000은 IRQ를 수신 할 때 모든 인터럽트를 비활성화 할 수 있습니다. 68000을 프로그래밍 한 적이 없습니다.

— LawrenceC

아 그래, 이제 기억 나 그리고 IIRC는 중첩 IRQ 처리를 허용함으로써 8259 칩 설계의 '우선 순위'측면에서 OS가 가능한 한 적은 인터럽트를 비활성화하도록 권장했지만 PC 인터럽트 라인은 우연히 할당되어 접근하다? 어느 쪽이든 CLI ... STI 하에서 상당한 양의 코드를 호출하는 것은 결코 의도가 아닙니다.

— Glenn Slayden