%20%EB%8B%A4%EC%88%98%EC%9D%98%20%EC%8B%A4%EC%8B%9C%EA%B0%84%20API%EB%A5%BC%20Base%EB%A1%9C%20%EC%9D%B4%EB%8F%99%ED%95%A9%EB%8B%88%EB%8B%A4.%20%EB%8B%A4%EC%9D%8C%20%EB%8B%A8%EA%B3%84%EB%8A%94%20%EB%AC%B4%EC%97%87%EC%9E%85%EB%8B%88%EA%B9%8C%3F.png)
표준을 읽는 동안 다음과 같은 여러 API를 발견했습니다.
POSIX 실시간 API와의 일관성을 위해 Issue 5에 도입되었습니다.
이슈 6에서 옵션 그룹 멤버십으로 표시됨
이슈 7(SUSv4)에서 기본 사항으로 이동했습니다.
묻다: 이는 모든 시스템이 "유닉스(R) V7"제품 표준은 실시간 시스템입니다. 실시간 요구 사항에 대한 이러한 시스템의 실제 기능은 무엇입니까?"
답변1
이것이 질문자가 추측하려고 하는 것입니다.
POSIX 스레드와 마찬가지로 실시간 API는 일반 애플리케이션에 유용하며, 이러한 API에 대한 사양은 아무런 장애 없이 구현될 수 있으며, 이러한 인터페이스를 지원하는 운영 체제가 더욱 보편화되므로 표준이 이를 기본으로 이동합니다. POSIX는 합의를 달성하기 위해 고안된 규범적 표준입니다.
실시간 API라고 해서 이를 사용하는 애플리케이션이 실시간 애플리케이션이라는 의미는 아닙니다. 이러한 API에 대한 서비스 품질을 보장하는 운영 체제(및 어느 정도 하드웨어)의 기능은 다양한 요소에 따라 달라지며 가장 중요한 것은 시스템 로드입니다.
유한한 시스템이 자신의 능력을 초과하는 실시간 요청을 무제한으로 처리할 수 있을 것이라고 기대하는 것은 비합리적입니다. 나는 실시간 프로그래밍에 대한 경험이 없지만 느낌을 바탕으로 추측한 것 중 하나는 실시간 애플리케이션에는 프로그래머가 달성해야 하는 잘 정의된 범위와 목표가 있으며 그 이상으로 실시간 시스템 사용자가 달성해야 한다는 것입니다. 범위와 목표를 초과하지 마십시오.