여러 RTOS (pSOS, VxWorks, QNX)에 대한 경험이 있지만 MicroC/OS II (ucos ii)를 처음 사용했습니다. 나는 ucos ii에 고유 한 것이 태스크를위한 고유 ID 대신 태스크를 고유하게 식별하는 우선 순위를 사용하고 모든 태스크가 다른 우선 순위를 가져야하므로 라운드 로빈 스케줄링이 지원되지 않는다는 것을 알고 있습니다. 그 정도는 이해합니다. 여기에 질문이 있습니다 :MicroC/OS II (ucos ii)의 우선 순위 변경 작업 ID가 변경됩니까?
OSTaskChangePrio()로 작업의 우선 순위를 변경하면 코드 또는 방금 우선 순위를 변경 한 작업의 우선 순위 (작업 ID)를 저장 한 다른 작업에 문제가 발생하지 않습니다. 실제로 우선 순위를 변경하면 작업의 ID가 변경됩니다. 어떻게 이것이 문제가되지 않습니까?
이 함수는 요청 된 우선 순위/ID를 가진 작업이 이미 있는지 확인하고 오류가 있으면 반환합니다. 따라서 작업의 우선 순위를 변경하려는 경우 작업 테이블에 적절한 위치를 남겨 두어야합니다. ucosii는 최대 255 개의 작업을 관리 할 수 있지만 모든 프로젝트에서 OS_LOWEST_PRIO 값을 지정해야합니다. 이렇게하면 사용 가능한 작업의 양을 제한 할 수 있습니다. ucosii는 psos 나 vxworks와 같지 않습니다. 핵이나 threadx와 같은 것입니다. 매우 얇은 OS입니다.
동적 스케줄링 알고리즘과 같은 것을 구현하거나 RTOS의 리소스 할당 알고리즘이 아니면 않는 한 우선 순위를 변경하고 싶지는 않을 것입니다. 그러한 경우 우선 순위로서 작업의 신원에 대해 신경 쓰지 않습니다. 하나는 작업의 마감일과 같은 요소에 따라 현재 실행해야하는 작업 만 신경 써야합니다.
정확합니다. OSTaskChangePrio를 사용하는 경우 더 이상 작업 우선 순위에 따라 작업을 식별 할 수 없습니다.
한 가지 예를 들자면 다른 작업을 시작하는 작업이 끝나면 우선 순위를 낮추고 싶을 수도 있습니다. 작업 ID를 효과적으로 변경하면 작업을 식별하는 방법으로 사용할 수 없다는 것을 의미합니다. 또한 ucos ii가 우선 순위 반전을 수행 할 때 ucos가 다른 작업에서 볼 수있는 작업 ID (우선 순위)를 실제로 변경시키는 지 여부도 불분명합니다. 즉, 우선 순위 역전이 발생하는 동안 원래 태스크 ID (우선 순위)를 사용하여 그 태스크 ID (우선 순위)가 없기 때문에 해당 태스크를 식별하기 위해 OS 호출이 실패합니까? – JonN