10.10.5 강의록 : RTOS

지난 시간 REVIEW
OS에서 말하는 것은 특정 Application을 High Speed로 하는 것이 아님 전체적인 효율성을 관리하는 것임.

S/W와 H/W가 어떻게 통신하는 가?
명령어를 가지고 오려면, H/W가 OS에 진입을 해야함. Application도 마찬가지. Application, OS는 H/W(자원)에 대해 빈번하게 요구를 해야함. 그러기 위해서는 OS에 진입.

사용자가 IE를 더블 클릭했을 때 : OS에서는 이 액션을 센싱함. IE는 이미 OS에서 프로세스화 되어 있지만, Active 상태가 아닌 것임. 이것을 지켜보던 OS가 요청이 들어왔을 때, 프로세스화 되어 있는(Dorment.휴지기 상태) IE를 Active 상태로 전환시켜준다.

OS를 USER(Application)관점에서 보게 되면, OS는 Service 프로그램이다
O.S = Scheduler(자체적으로 돌아감) + Service Programs(ISR(interrupt Service Routine) and Exception Service, System Call Service)

//System Call Service : Process, Memory management, 세마포, IPC, Messege, 동기화, Timer 등의 클래스로 분류될 수 있다.
//이때 System Call Service는 Super Class로 볼 수 있다.


설계를 할 때 어떤 관점에서 설계를 해야 하는가?

design Strtegies
1. Object-Oriented Notation (Data Structure, Methods(Algorithms) 등에 대해 자세하게 명세해야 한다)
2. Input/Output Interface에 대해 정확하게 Define 해야 함. (From-To, Object, Method)
3. Relationship to often kernel Component

Specification : function , condition, interface
Diagram : Control flow(CPU program count. CPU 처리 제어권), Data flow(Data가 흘러다니는 것임. 두개 이상의 컴포넌트에서 동일한 데이터를 사용할 경우, 일관성의 문제가 생김, 무결성 유지. 일관성 유지를 위해서. 데이터가 변경이 되더라도 Data가 항상 유효하도록한다.)
Documentation/Proesentation(ppt, word) : 6~7 pages
future work

Process, IPC, Sync, Timer 에 대해서 발표준비



Task Schedulers
Task란 Unit of scheduling, Execution Unit by CPU => OS에 의해 스케쥴링 되어 CPU에서 처리되는 실행 단위

TCB(Task  Control Block) : Task Information을 가지고 있음.
Task ID, Task Start Address, Task Resume Address, Initial priority, Current priority, Crrent state, Current stack pointer, Current registers, Task Next pointer, Task Previous Pointer, Task Memory Address

Task ID

Task Start Addr

Resume Addr

IPC

.

.

.

 
Context Switching이 뭐냐? Task의 문맥(정보: TCB)이 교환 되는 것임. 궁극적으로 Task의 정보가 옮겨지는 것임. Ready 상태 등의 상태에 있는 Task들의 상태가 변화되는 것임. 결국은 CPU의 제어권이 변화되는 것임.

CPU의 정보를 TCB로 보냈다가, 다시 TCB의 정보를 CPU로 보내야 한다. : 이게 Context Switching

Priority Scheduling : Task의 중요도를 나타냄. 0가 우선순위가 제일 높고, 255가 제일 낮다. 다음에 누가 CPU에 의해 처리될 것인가를 결정. Who is next?
Priority 값은 누가 지정해주는 가? Same Priority의 경우에는 roundrobin,  ->우선순위정책이 될 수가 없다.
우선순위 값은 자동으로 정해주는 게 아니라, 시스템 스펙을 할 때, 시스템 설계자가 지정해준다.

Task State - Run, Ready, Wait//스케쥴링 되려면 ready state에 있어야함
TCB에 있는 state 정보를 바꿔줘야 하마. Wait에서는 우선순위가 필요없고, Ready에서는 프로세스 상태 및 우선순위를 TCB에 갱신해줘야함. 
Task A가 처리되려면 Run 상태에 있고 메시지가 있어야 하는데, 메시지를 OS에 요청했을 때, OS가 없다고 하면  wait 상태로 바꾸고... 프로세스로 점프? (잘 모르겠음 --) //Run - >Wait는 자원이 없을 경우에 자원요청하는 메시지를 보내면 OS가 자원이 없다고 하면 메시지 매니저가 없다고 알려줌. 따라서 Run->Wait 로 갈 때는 스케줄러가 아닌 메시지 매니저가 처리함.
Ready-Run만 스케줄러가 하고, Run-wait, Ready-Wait는 메시지 매니저가 관리

Task Initialization : System Call 을 써서 한다. 초기화 테스크가 존재.

초기화는 3단계
하드웨어 초기화 :  하드웨어를 연결하면 특정 메모리에 대해 연결이 됨. 이것은 인터럽트가 걸림. 메모리 영역 안에는 Status bit, Control bit, Data 메모리 영역이 있다. 초기에 Status bitsms 무조건 0 이다. 따라서 비트를 세트시켜서 active 상태로 바꿔줘야한다.
OS 초기화
Application 초기화

테스크 관리자가 해야 할 시스템 콜 : 1)Task_Create(), 2)Set_priority(), 3)Change_state(), 4)Task_resume(), 5)Task_Start(), 6)Task_Terminate()//스스로 종료, 7)Task_Signal()//다른 Task한테 신호를 보낼 때(동기화), 8)Task_Kill()//다른 Task를 종료 시키는 것, 9)Get_Priority()
Terminate, Kill을 시키면 모드 Dormant(휴지기)상태로 바껴야 한다. Dormant 상태는 스케쥴링 대상이 아님
위의 시스템 콜들은 커널이 아닌 테스크에서 사용하는 시스템 콜이다.



ReadyQue 필요.



해야할 것들. 가정. 우리는 Preemptive Kernel(시스템 콜이나 인터럽트가 왔을 때 리스케줄링한다). 일단 TCB 구조 정의, 테스크 생성, ....
일단 Run-Ready 상태에서의 일어나는 일들과. 테스크에서의 시스템 콜들에 대해서 설계, 각 스테이트 별로 레디큐에 테스크 연결, 웨이트 큐에 테스크 연결 등의 링크드 리스트던 뭐던 일단 자료구조를 만들어서 포인터로 연결해주도록 해야함.

스케쥴러(정의, 액션 등의 모든 것 설계), 시스템 콜 설계