정의
runnable 태스크 매핑은 runnable을 깨우는 각 RTE 이벤트를 어느 OS 태스크에서 처리할지, 그리고 그 태스크 안에서 몇 번째로 놓을지를 구성 시점에 정하는 작업이다.[1]
소프트웨어 컴포넌트의 구현을 이루는 runnable은 그 자체로 스케줄링 단위가 아니다. runnable은 태스크의 컨텍스트에서 실행되고, 어느 시점에 어느 태스크가 CPU를 잡을지를 정하는 것은 운영체제 스케줄러다.[2] 그래서 컴포넌트 설계가 끝난 뒤에도 “이 조각들을 어떤 태스크에 어떤 순서로 넣을 것인가”라는 문제가 따로 남는다. 태스크 객체 자체는 OSEK 태스크에서 다룬다.
매핑 구성
매핑은 런타임 환경 구성의 한 자리다. 구성 컨테이너 하나가 RTE 이벤트 하나를 맡아, 그 이벤트가 깨우는 runnable이 놓일 OS 태스크와 그 태스크 안에서의 위치를 지정한다. 태스크 안에서 runnable이 실행되는 순서는 이 위치 값이 정하며, 서로 다른 종류의 이벤트로 깨어나는 runnable들이 한 태스크에 섞여 있어도 위치 값 하나로 전체 순서가 정해진다.[1]
어떤 태스크 유형을 쓸 수 있는지는 무엇을 한데 묶느냐에 달려 있다. runnable 하나만 담거나 활성화 주기가 같은 runnable 여럿을 담는 태스크는 basic task로 충분하고, 이때도 태스크 안의 실행 순서는 반드시 지정되어야 한다. 활성화 주기가 서로 다른 runnable을 한 태스크에 묶으면 extended task가 쓰인다.
매핑이 감시 목적으로 갈라지기도 한다. 실행 순서를 통제하는 태스크와 runnable이 실제로 매핑되는 태스크를 따로 지정할 수 있는데, 이 구성이 의도대로 돌려면 감시 대상 runnable이 매핑된 태스크의 우선순위가 순서를 통제하는 태스크보다 높아 즉시 선점이 일어나도록 운영체제 쪽 우선순위와 스케줄링 속성이 맞춰져 있어야 한다.
태스크 안의 순서
한 태스크에 모인 runnable들의 실행 순서는 구성이 정한 위치 값이 전부이고, 그 사이에는 스케줄러가 끼어들지 않는다. 그래서 데이터 의존이 있는 두 runnable을 한 태스크에 넣을 때 순서를 어떻게 잡느냐가 결과를 가른다.
생산자가 소비자보다 앞에 놓이면 순방향 통신이 되어 소비자는 같은 주기 안에서 방금 만들어진 값을 읽는다. 반대로 소비자가 생산자보다 앞에 놓이면 역방향 통신이 되고, 소비자는 이전 주기에 생산된 값을 읽으므로 한 주기만큼 지연이 생긴다.[3]
주기가 다른 태스크 사이
태스크 경계를 넘어가면 순서의 문제가 주기의 문제로 바뀐다. 인과 사슬을 이루는 태스크들의 주기가 서로 다르면 두 가지 왜곡이 생긴다.[3]
소비자의 주기가 생산자의 주기보다 길면 언더샘플링(undersampling)이 되어 데이터가 유실된다 — 생산자가 만든 값 가운데 일부는 읽히기 전에 다음 값으로 덮어써진다. 반대로 소비자의 주기가 더 짧으면 오버샘플링(oversampling)이 되어 데이터가 중복된다 — 같은 값이 서로 다른 소비 실행에서 여러 번 읽힌다.[4]
이 왜곡은 사슬 전체의 지연을 계산할 때 곧바로 문제가 된다. 게다가 센싱·스케줄링·제어·구동 각 단계의 지터와 시스템에 여러 클록이 존재할 가능성이 더해지면서 지연 계산의 불확실성이 커진다. 사슬 전체를 어떻게 다루는지는 종단 간 타이밍에서 다룬다.
암묵 통신
한 태스크 안에서도 데이터 일관성 문제는 남는다. 런타임 환경은 두 가지 통신 방식을 제공하는데, 명시적 방식에서는 runnable이 API를 직접 불러 값을 읽고 쓰지만, 암묵적 방식에서는 runnable이 송수신을 스스로 일으키지 않는다.[1]
암묵 읽기에서는 runnable이 시작할 때 필요한 데이터가 복사 의미론으로 준비되고, 런타임 환경은 그 복사본이 runnable이 끝날 때까지 바뀌지 않도록 보장한다. 여러 runnable이 같은 데이터를 필요로 하면 같은 버퍼를 공유할 수도 있다. 암묵 쓰기는 그 반대여서, runnable이 쓴 값은 runnable이 끝난 뒤에 내보내진다. 그래서 쓰기 호출이 runnable 코드의 어디에 있든 결과가 같고, 같은 데이터 요소에 여러 번 썼다면 마지막 것만 남는다.
암묵 읽기와 무한 루프
암묵 읽기는 runnable이 실제로 종료한다는 것을 전제한다. 끝나지 않고 계속 도는 runnable은 갱신된 데이터를 영영 보지 못한다.[1]