"소프트"실시간 운영 체제가 실제로 제공하는 보장

"하드"실시간 운영 체제가 무엇인지 알고 있습니다. 응용 프로그램 프로그래머와 계약을 제공하는 스케줄러가있는 운영 체제입니다. 응용 프로그램은 각 자원 할당 요청에 대한 기한을 제공합니다. 경우 마감일 요청이 가능 , 스케줄러는 각 자원 마감일 전에 요청하는 응용 프로그램에 할당됩니다 보장합니다. 애플리케이션 프로그래머가 특정 요청의 최대 대기 시간 및 최소 처리량을 추론 할 수 있도록 보장하기에 충분합니다.

"부드러운"실시간 시스템에 대한 모든 정의는 공허 해 보입니다. 위키 백과는 말합니다

최종 기한이 지나면 결과의 유용성이 저하되어 시스템의 서비스 품질이 저하됩니다.

어. 괜찮아. 이 기준에 따르면 Windows 95는 소프트 실시간 시스템이었고 3BSD도 마찬가지였으며 Linux도 마찬가지였습니다. Wikipedia는 훌륭한 소스는 아니지만 다음 두 가지 Google 히트는 그리 나쁘지 않습니다. 예를 들어 http://users.ece.cmu.edu/~koopman/des_s99/real_time/ 은 말합니다.

소프트 실시간 시스템에서는 드물게 발생하는 피크로드에서의 성능 저하가 허용됩니다.

그것은 계약이 아니며, 아무 말도하지 않는 멋진 방법입니다.

실제 운영 체제에서 제공하는 실제 소프트 실시간 보증 / 계약의 예는 무엇입니까?

양식의 답변을 찾고 있습니다.

(OS-name)에서 프로그래머가해야 할 일 (what-themer-needs-to-do)은 운영 체제가 보장하는 것 (what-the-system-guarantees)입니다.

올바른 결과를 얻었으며 Wikipedia는 최대한 유익한 정보를 제공합니다. 소프트 실시간은 공식적인 특성화가 아니라 가치 판단입니다. "부드러운 실시간"이라고 말하는 또 다른 방법은 "실시간 이었으면 좋겠어요", 또는 더 정확하게는 "실시간이어야하지만 너무 어렵다"입니다.

실제로 보증의 형태로 말하고 싶다면 특정 성능을 보장하는 것이 아니라 최선의 노력을 보장하는 것입니다.

또는 Erlang FAQ 를 인용하려면 (Erlang은 원래 전화 통신용으로 설계된 프로그래밍 언어입니다.)

소프트 실시간이란 무엇입니까?

Cynics는 "기본적으로 아무것도 없다"고 말할 것입니다.

(…) 많은 텔레콤 시스템은 [실시간보다] 덜 엄격한 요구 사항을 가지고 있습니다. 예를 들어, "데이터베이스 조회는 97 %의 경우 20ms 미만이 소요됩니다"라는 라인을 따라 통계적 보증이 필요할 수 있습니다. Erlang과 같은 소프트 실시간 시스템을 사용하면 이러한 종류의 보증을 할 수 있습니다.

그리고 이것은 유용한 정의를 제공합니다. 소프트 실시간은 모든 작업을 수행하는 데 소요되는 총 시간을 최적화하는 것이 아니라 특정 시간을 소비 하지 않고 각 개별 작업에 최적화 된 디자인을 나타냅니다 . 예를 들어, 소프트 실시간 시스템은 10ms 내에 요청의 99.9 %를 완료하고 초당 100 개의 요청을 처리하는 것을 목표로합니다. 비 실시간은 초당 200 개의 요청을 진행하지만 가끔 요청이 차단되도록 할 수 있습니다. 50ms 이상 어려운 실시간은 15ms마다 하나의 요청을 보장합니다.

소프트 실시간은 마감 기한을 놓치면 서비스 성능이 저하되지만 성능이 중요하지 않은 응용 프로그램에 사용됩니다. 멀티미디어 및 전화 통신이 일반적인 사용 사례입니다. 각 오디오 또는 비디오 프레임은 시간에 맞춰 렌더링되어야합니다. 그렇지 않으면 건너 뛰어야합니다. 그러나 프레임을 건너 뛰는 것은 세상의 끝이 아닙니다. Erlang의 설계자들은 다른 문제들에 대해서도 신뢰성에 대한 비슷한 목표를 가지고있었습니다. 그들은 전화 교환이 때때로 전화를 끊는 것이 더 낫다는 것을 관찰했지만, 교환이 전체적으로 계속 작동 할 것임을 확신하는 것이 모든 비용으로 연결을 유지하는 데 치명적인 오류가 발생할 위험이 있습니다.

반대로 모터 제어와 같은 소프트웨어는 소프트웨어가 마감일을 놓치지 않아야합니다. 여기에는 비용이 발생합니다. 전체 성능이 일반적으로 느리고 비교적 간단한 동작 만 수행 할 수 있습니다. 스펙트럼의 다른 측면에서, 숫자 크 런칭 응용 프로그램은 일반적으로 전체 성능에만 관심이 있습니다. 중요한 것은 각 열의 계산 속도가 아니라 1000x1000 행렬의 곱셈 속도입니다.

-rt (실시간) 패치 세트가있는 Linux는 일정하지 않은 것처럼 보이는 흥미로운 보장을 제공하는 스케줄러를 제공합니다. (어떻게 보장을 실제로 사용할 수 있는지는 확실하지 않지만)

Linux-rt SCHED_FIFO스케줄링 정책은 다음과 같이 작동합니다. 사용자는 모든 프로세스에 우선 순위를 지정합니다. ( "실시간"프로세스의 우선 순위 번호는 0-99이며, 전통적인 Unix nice값 -20-19는 우선 순위 100-139에 맵핑됩니다. 따라서 "0"은 "가장 높은"우선 순위이고 "139"는 "가장 낮은"입니다 " 우선 순위.)

스케줄러는 언제든지 프로세서 시스템 N에서 가장 높은 우선 순위의 실행 가능한 작업을 예약합니다 N. 커널 내부의 우선 순위 역전 문제를 피하기 위해 많은 노력을 기울였습니다. 프로세스가되면 A실행 가능하게하고 다른 실행중인 프로세스보다 더 높은 우선 순위를 가지고 B, A즉시 선점 할 것이다 B.

그러나 엄격한 시간 보증은 제공되지 않습니다. 선점을 실제로 수행하는 데 소요되는 시간은 이론적으로 임의로 길 수 있습니다. 또한 우선 순위가 낮은 작업이 대기 시간이 긴 많은 I / O를 시작할 수있는 방법이있는 것 같습니다. I / O가 완료되면 우선 순위가 낮은 작업에 대한 인터럽트 핸들러가 우선 순위가 높은 작업 인 인터럽트 우선 순위의 형식 인 인터럽트를 처리 할 수 ​​있습니다.

따라서 제공되는 제한 보증은 다음과 같습니다. 우선 순위가 가장 높은 단일 프로세스가있는 경우 실행 가능할 때마다 OS가 실제로 제공 할 수있는 모든 프로세서 리소스를 가져옵니다. 가장 높은 우선 순위 프로세스가 소비하는 프로세서 리소스의 양에 대한 상한이 좋으면 두 번째로 높은 우선 순위 프로세스 등에서 사용할 수있는 리소스를 합리적으로 정확하게 추정 할 수 있습니다.

Linux 실시간 스케줄러를 설명하는 심층 기사는 http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler 입니다.

"부드러운 실시간"을 정의하려면 "하드 실시간"과 비교하는 것이 가장 쉽습니다.

우연히 말하면, 대부분의 사람들은 정보 나 사건을 "실시간"으로 간주하는 비공식적 인 정신 모델을 내재적으로 가지고 있습니다

• 지각 된 통화와 관련 될 수있는 지연 (대기 시간)으로 표시되는 경우

즉, 정보 또는 사건이 수용 가능한 만족스러운 가치를 지니고있는 기간.

"하드 실시간 (hard real-time)"에 대한 수많은 임시 정의가 있지만, 그 정신 모델에서 하드 실시간은 "if"라는 용어로 표현됩니다. 특히, 작업과 같은 실시간 작업에 완료 기한이 있다고 가정하면 모든 작업이 완료된 이벤트의 만족스러운 가치는 모든 작업이 기한을 충족시키는 특별한 경우로 제한됩니다.

어려운 실시간 시스템은 응용 프로그램과 시스템 및 환경에 대한 모든 것이 정적이고 사전에 알려진 것으로 가정합니다. 예를 들어, 어떤 작업, 주기적, 도착 시간, 기간, 마감 기한 리소스 충돌이 없으며 시스템의 전체적인 시간 진화. 항공기 비행 제어 시스템 또는 자동차 제동 시스템 및 기타 여러 경우에서 이러한 가정은 일반적으로 모든 마감일이 충족되도록 충족 될 수 있습니다.

이 정신 모델은 하드 및 소프트 실시간을 모두 포괄 할 수있을 정도로 고의적으로 매우 유용하며 일반적으로 소프트는 "그 정도까지"라는 문구로 수용됩니다. 예를 들어, 작업 완료 이벤트에 차선이지만 허용 가능한 값이 있다고 가정하십시오.

• 과제의 10 % 이하가 마감일을 놓친다
• 지각이 20 %를 넘지 않는 작업
• 또는 모든 작업의 ​​평균 지각이 15 %를 넘지 않아야합니다.
• 또는 모든 작업 중 최대 지각이 10 % 미만입니다.

이들은 모두 많은 응용 분야에서 소프트 실시간 사례의 일반적인 예입니다.

방과 후에 아이를 태우는 단일 작업 응용 프로그램을 고려하십시오. 실제 마감일이 없을 수도 있습니다. 대신 이벤트가 발생하는 시점에 따라 귀하와 자녀에게 가치가 있습니다. 너무 일찍 자원 (예 : 시간)을 낭비하고 너무 늦으면 자녀가 홀로 남겨져 잠재적으로 해를 입을 수 있거나 최소한 불편을 겪을 수 있기 때문에 부정적인 가치가 있습니다.

정적 하드 실시간 특수 사례와 달리 소프트 실시간은 작업 및 시스템에 대한 최소한의 응용 프로그램 별 가정 만 수행하므로 불확실성이 예상됩니다. 자녀를 데리러 오려면 학교까지 운전해야하며 날씨, 교통 상황 등에 따라 시간이 역동적입니다. 최악의 운전 시간) 그러나 다시 이것은 자원을 낭비하고 있습니다 (시간과 가족 차량을 점유하여 다른 가족 구성원의 사용을 거부 할 수 있음).

이 예는 자원 낭비 측면에서 비용이 많이 들지 않지만 다른 예를 고려하십시오. 모든 군사 전투 시스템은 부드러운 실시간입니다. 예를 들어, 목표 기동으로 업데이트 된 미사일을 사용하여 적대적인 지상 차량에 항공기 공격을 수행하는 것을 고려하십시오. 강좌 업데이트 작업을 완료하기위한 최대 만족도는 목표물에 대한 직접적인 파괴적 파업에 의해 달성됩니다. 그러나 이러한 결과를 확실하게하기 위해 리소스를 과도하게 프로비저닝하려는 시도는 대개 너무 비싸고 불가능할 수도 있습니다. 이 경우, 미사일이 목표물에 접근 할 수 없을 정도로 근접해 있으면 만족스럽지 않을 수 있습니다.

분명히 전투 시나리오에는 자원 관리에 의해 수용되어야하는 가능한 많은 동적 불확실성이 있습니다. 소프트 실시간 시스템은 산업 자동화와 같은 많은 민간 시스템에서도 매우 일반적이지만 군사 시스템은 수용 가능한 만족스러운 가치를 달성하기 위해 가장 위험하고 긴급한 시스템입니다.

실시간 시스템의 핵심은 "예측 가능성"입니다. 어려운 실시간 사례는 하나의 특별한 예측 가능성 사례에만 관심이 있습니다. 즉, 작업이 모두 기한을 준수하고 해당 이벤트에서 가능한 최대 값을 달성 할 수 있습니다. 이 특별한 경우를 "결정 론적"이라고합니다.

예측 성의 스펙트럼이 있습니다. 대부분의 실시간 시스템 (즉, 소프트 시스템)은 예를 들어 작업 완료 시간 및 그 결과로 얻은 값에 대한 비 결정적 예측 가능성을가집니다. 일반적으로, 예측 가능성과 그에 따른 가치는 필요에 따라 결정 론적 종점에 가깝지만 육체적으로 불가능하거나 지나치게 비쌀 수있는 가격 (전투에서 또는 학교에서 자녀를 태울 때)으로 만들 수 있습니다.

소프트 실시간에는 응용 프로그램 별 확률 모델 (공통 빈도 모델이 아님)이 선택되므로 이벤트 대기 시간 및 결과 값에 대한 추론을위한 예측 가능성 모델이 필요합니다.

허용 가능한 값을 제공하는 위의 이벤트 목록을 다시 참조하면 다음과 같이 비 결정적 사례를 추가 할 수 있습니다.

• 작업이 마감 시간을 5 % 이상 놓치지 않을 확률은 0.87보다 큽니다.

미사일 방어 응용 프로그램에서는 전투에서 공격이 항상 방어보다 유리하다는 사실을 고려할 때 다음 두 실시간 컴퓨팅 시나리오 중 원하는 것을 선택하십시오.

• 모든 적대적 미사일의 완벽한 파괴는 가능성이 거의 없거나 불가능하기 때문에, 가장 위협적인 (예 : 목표에 따라) 적대적 미사일이 성공적으로 차단 될 가능성을 극대화하기 위해 방어 자원을 할당하십시오. 적대적 미사일을 코스 밖으로 이동할 수 있음);

• 정적이 아니라 동적이기 때문에 실시간 컴퓨팅 문제가 아니며 기존의 실시간 개념과 기술은 적용되지 않으므로 소프트 실시간 R & D에 관심이 없습니다.

실시간 컴퓨팅 커뮤니티 (다른 비계산 분야는 아님)에서 소프트 실시간에 대한 다양한 오해에도 불구하고 소프트 실시간은 매우 일반적이며 강력하며 하드 실시간에 비해 잠재적으로 매우 복잡합니다.

OP 질문에 직접 대답하려면 다음을 수행하십시오.

• 하드 실시간 시스템은 결정적인 보증을 제공 할 수 있습니다. 가장 일반적으로 모든 작업이 마감일을 충족 시키거나, 인터럽트 또는 시스템 호출 응답 시간이 항상 x보다 작습니다. — 매우 강력한 가정이 이루어지고 올바른 중요한 것은 정적이고 사전에 알려진 것입니다 (일반적으로 하드 실시간 시스템에 대한 보장은 단순한 경우를 제외하고는 공개 연구 문제입니다)

• 소프트 실시간 시스템은 결정 론적 보증을하지 않으며, 애플리케이션 별 기준에 따라 현재 동적 상황에서 실행 가능한 타임 라인의 분석 가능한 특정 적시성 적시성 및 예측 가능성을 제공하기위한 것입니다. 분명히 어려운 실시간은 부드러운 실시간의 간단한 특수 사례입니다. 분명히 부드러운 실시간 분석 비결정론 적 보증은 제공하기가 매우 복잡 할 수 있지만, 대부분의 경우 정적이 아닌 동적이기 때문에 가장 일반적인 실시간 사례 (전투와 같이 가장 위험한 안전 크리티컬 사례 포함)에서는 필수입니다.

내 웹 사이트 real-time.org 에서 실시간, 하드 실시간, 소프트 실시간, 예측 가능성, 결정론 및 관련 주제에 대해 훨씬 더 상세하게 논의 했습니다 .