정의
태스크(task)는 OSEK/VDX 운영체제가 관리하는 실행 단위로, 함수를 실행할 틀을 제공한다. 운영체제는 태스크를 동시적·비동기적으로 실행하며 실행 순서는 스케줄러가 정한다.[1]
복잡한 제어 소프트웨어는 실시간 요구에 따라 여러 부분으로 나눌 수 있고, 그 부분들을 구현하는 수단이 태스크다. OSEK/VDX 운영체제는 태스크 전환 메커니즘인 스케줄러와, 다른 시스템·응용 기능이 하나도 활성이 아닐 때 도는 유휴 메커니즘(idle mechanism)을 함께 제공한다.[1]
태스크 개념 일반과 RTOS 안에서의 자리는 실시간 운영체제에서 다룬다. 이 페이지는 OSEK/VDX 규격이 태스크 객체에 부여한 상태 모델과 속성을 다룬다.
상태 모델
프로세서는 한 시점에 한 태스크의 명령만 실행할 수 있는데 여러 태스크가 동시에 프로세서를 두고 겨루므로, 태스크는 여러 상태 사이를 오간다. 태스크 상태 전이와 관련해 필요할 때마다 태스크 컨텍스트를 저장하고 복원하는 일은 운영체제가 맡는다.[1]
extended task는 네 상태를 갖는다. running은 CPU가 그 태스크에 배정되어 명령이 실행되는 상태이고, 한 시점에 이 상태에 있을 수 있는 태스크는 하나뿐이다. ready는 running으로 갈 기능적 전제가 모두 갖춰졌고 프로세서 배정만 기다리는 상태다. waiting은 적어도 하나의 이벤트를 기다려야 해서 실행을 이어 갈 수 없는 상태이며, suspended는 태스크가 수동적으로 놓여 활성화를 기다리는 상태다.
전이는 여섯 가지다. activate는 시스템 서비스가 태스크를 suspended에서 ready로 올리며, 이때 운영체제는 실행이 첫 명령부터 시작되도록 보장한다. start는 스케줄러가 고른 ready 태스크가 실행되는 전이이고, preempt는 스케줄러가 다른 태스크를 시작하기로 결정해 running 태스크를 ready로 되돌리는 전이다. terminate는 running 태스크가 시스템 서비스로 스스로를 suspended로 되돌리는 전이다. wait는 시스템 서비스가 일으키는 running에서 waiting으로의 전이이고, release는 기다리던 이벤트가 적어도 하나 발생했을 때 waiting에서 ready로 돌아오는 전이다.
suspended에서 waiting으로 바로 가는 전이는 없다. 중복이고 스케줄러 복잡도만 키우기 때문이다.
자기 종료 제약
태스크 종료는 자기 종료만 가능하다. 이 제약은 운영체제의 복잡도를 줄인다. 모든 태스크는 코드 끝에서 스스로를 끝내야 하며, TerminateTask나 ChainTask를 부르지 않고 태스크를 끝내는 것은 엄격히 금지되고 정의되지 않은 거동을 낳는다.[1]
두 태스크 유형
basic task의 상태 모델은 extended task와 거의 같지만 waiting 상태가 없다는 점만 다르다. 그래서 basic task가 프로세서를 놓는 계기는 셋뿐이다 — 스스로 종료하거나, 운영체제가 더 높은 우선순위 태스크로 전환하거나, 인터럽트가 발생해 프로세서가 ISR로 넘어가는 경우다.[1]
extended task는 WaitEvent 시스템 서비스를 쓸 수 있다는 점에서 갈린다. 이 호출은 waiting 상태로 이어질 수 있고, waiting 상태는 실행 중인 태스크를 끝내지 않은 채 프로세서를 더 낮은 우선순위 태스크에 넘길 수 있게 한다.
두 유형의 대가는 분명하다. basic task는 동기화 지점이 태스크의 시작과 끝뿐이므로, 내부에 동기화 지점이 필요한 응용 부분은 여러 basic task로 쪼개 구현해야 한다. 대신 런타임 컨텍스트로 요구하는 RAM이 적다. extended task는 어떤 동기화 요구가 걸려 있든 하나의 태스크 안에서 일관된 작업을 처리할 수 있고, 처리에 필요한 정보가 없으면 waiting으로 넘어갔다가 이벤트가 도착하면 빠져나온다. 그 대신 관리가 더 복잡하고 시스템 자원을 더 쓴다.
태스크 유형은 선점 가능 여부와 독립이다. 완전 선점 시스템에 basic task를 둘 수 있고, 비선점 시스템에 extended task를 둘 수 있다.
활성화와 우선순위
태스크 활성화는 ActivateTask 또는 ChainTask 서비스로 수행하며, 활성화된 태스크는 첫 문장부터 실행할 준비가 된다. C 함수처럼 인자를 넘기는 방식은 지원하지 않으므로 값은 메시지 통신이나 전역 변수로 전달한다.[1]
스케줄러는 태스크 우선순위를 근거로 다음에 running으로 옮길 ready 태스크를 고른다. 값 0이 가장 낮은 우선순위이고 숫자가 클수록 높은 우선순위다. 효율을 위해 동적 우선순위 관리를 지원하지 않으므로 우선순위는 정적으로 정해지고 사용자는 실행 중에 바꿀 수 없다. 다만 우선순위 상한 프로토콜이 적용되는 경우처럼 운영체제가 태스크를 일시적으로 더 높은 우선순위로 다룰 수는 있다. 우선순위를 어떤 기준으로 배정할지는 고정 우선순위 스케줄링의 문제다.
같은 우선순위의 태스크들은 활성화 순서에 따라 시작한다. 선점된 태스크는 자기 우선순위 준비 큐에서 가장 오래된 태스크로 취급되고, waiting에서 풀려난 태스크는 같은 큐의 가장 새로운 태스크로 취급된다. 스케줄러가 다음 태스크를 정하는 절차는 세 단계다 — ready와 running 상태의 태스크를 모두 찾고, 그중 우선순위가 가장 높은 집합을 고르고, 그 집합에서 가장 오래된 태스크를 찾는다.
다중 활성화 요청은 basic task에만 열려 있다. 이미 활성화된 basic task에 대한 병행 활성화 요청을 운영체제가 받아 기록하는 것이며, 병행 요청의 최대 개수는 시스템 생성 시 태스크별 속성으로 정한다. 최대 개수에 이르지 않았으면 요청은 우선순위별로 활성화 순서대로 큐에 쌓인다.
정적 구성 속성
OSEK/VDX 운영체제의 모든 시스템 객체는 사용자가 정적으로 결정하며, 객체를 동적으로 만드는 시스템 서비스는 존재하지 않는다. 객체의 실제 생성은 시스템 생성 단계에서 이뤄지고, 응용 소스에 쓰는 선언은 그 객체에 대한 외부 참조일 뿐이다.[1]
태스크 객체가 구성 언어에서 갖는 표준 속성은 다음과 같다.[2]
| 속성 | 뜻 |
|---|---|
| PRIORITY | 태스크 우선순위. 상대적 순서만 의미가 있고, 0이 최저이며 값이 클수록 높다 |
| SCHEDULE | 선점 가능 여부. FULL은 선점 가능한 태스크, NON은 선점 불가한 태스크 |
| ACTIVATION | 큐에 쌓을 수 있는 활성화 요청의 최대 개수. 1이면 동시에 한 번의 활성화만 허용된다 |
| AUTOSTART | 시스템 기동 절차에서 활성화할지 여부. 참이면 하위 속성으로 대상 application mode 목록을 지정한다 |
| RESOURCE · EVENT · MESSAGE | 태스크가 접근하는 자원·이벤트·메시지 목록 참조 |
선점 가능한 태스크와 선점 불가한 태스크가 한 시스템에 섞이면 스케줄링 정책은 실행 중인 태스크의 선점 속성에 따라 정해진다. 선점 방식 자체의 분류는 실시간 스케줄링 참조 모델에서 다룬다.
conformance class
응용이 시스템에 요구하는 것과 특정 시스템이 낼 수 있는 능력이 제각각이므로, OSEK/VDX는 운영체제 기능을 conformance class라는 묶음으로 나눈다. 목적은 셋이다 — 기능을 이해하고 논의하기 편한 묶음을 제공하고, 미리 정한 선을 따르는 부분 구현이 인증받을 수 있게 하고, 응용을 고치지 않고 낮은 등급에서 높은 등급으로 올라가는 경로를 만드는 것이다. 인증을 받으려면 등급 전체를 구현해야 하고, 등급은 실행 중에 바꿀 수 없다.[1]
등급을 가르는 속성은 셋이다 — 다중 활성화 요청, 태스크 유형, 우선순위당 태스크 수. 그 밖의 기능은 명시적으로 달리 규정하지 않는 한 모든 등급에서 필수다.
| 등급 | 태스크 유형 | 우선순위당 태스크 | 다중 활성화 요청 |
|---|---|---|---|
| BCC1 | basic만 | 1개 | 불가 |
| BCC2 | basic만 | 여러 개 | basic task에 한해 가능 |
| ECC1 | basic과 extended | 1개 | 불가 |
| ECC2 | basic과 extended | 여러 개 | basic task에 한해 가능 |
규격은 등급마다 최소 요구치도 못 박아 둔다. 이식성은 이 최소 요구를 넘지 않을 때만 가정할 수 있다. BCC1과 BCC2에서는 suspended가 아닌 태스크가 8개, 태스크 우선순위가 8단계이고, ECC1과 ECC2에서는 두 값이 각각 16으로 늘며 태스크당 이벤트가 8개다. 어느 등급에서도 extended task에는 다중 활성화 요청이 허용되지 않는다.
인터럽트 처리 레벨과의 관계는 OSEK 인터럽트 처리에서, 알람에 의한 자동 활성화는 OSEK 카운터와 알람에서, 태스크 전환 지점에 끼어드는 사용자 코드는 OSEK 훅 루틴에서 다룬다.