[OS] LDE machanism (limited direct execution)

📌Direct execution
: OS가 제어 및 프로그램 실행에 관여하지 않고, resource 준비만 하던 초기의 형태
- 문제점
1. 함부로 사용하면 안되는 함수, 요청을 사용자가 수행해버릴 수 있는 구조
2. 현재 수행중인 프로세스를 OS 마음대로 끊을 수 없다.
    time sharing을 위해 OS가 필요할 때 강제로 멈추고 CPU 권한을 가져올 수 있어야한다.
 
📌LDE (limited direct execution) → DE의 개선안
 
문제1 피드백 : 사용자가 수행하면 안되는 부분은 OS가 수행
- 무엇을? : general mem access, disk I/O, 특정 권한을 갖는 instruction
- 어떻게? : user mode ↔ kernel mode (hw resource 필요한건 OS에게 요청해줘!)
- system call : 특정 권한 갖는 instruction의 실행시 발생
user process가 trap instruction 수행 → system call → user mode에서 kernel mode로! (권한 레벨 상승) → 요청 완료 후 OS가 return-from-trap instruction 수행 → 다시 user mode로 돌아가 (권한 레벨 하락) next instrucion 수행
 
문제2 피드백 : OS가 CPU권한을 가질 수 있어야한다
1. a cooperative approach : wait for system calls
: 사용자가 알아서 OS에게 권한 가질 기회 제공(yield : 나 지금 권한 필요없어! 너 할래?)
- system call 수행 + illegal operation 제어
- 문제점 : 프로세스가 무한루프에 빠지고 + system call 안한다면?
               → 프로세스가 stuck된다 → OS가 강제로 멈출 수 없기에 시스템 전체가 stuck
2. a non-cooperative approach : the OS takes control
: (현재 사용되는 방식) timer 통해 현제 프로세스 멈춰서 주기적, 강제적으로 OS가 권한 가져올게!
→ 프로세스 멈출 때 context 등 정보 저장, OS 다 쓴 후 저장해둔 것 가져옴
 
🌟context swtiching
: OS가 프로세스 멈추고 재수행하는 작업을 안전하게 할 수 있게 함.
- context : 프로세스 수행에 필요한 reg 정보
- context saving(현재 context 저장) → context restoring(재수행시 복구) → context switching (PCB1 → PCB2)
 
context switching time; time slice 줄일수록 response time 줄어드는가?
time slice 줄이면 → context switching 빈번히 발생 → mem에 빈번히 접근해야함+수행비용 발생 → system 성능 저하 context switching overhead : time slice < context switching time
결론 : time slice 작다고 무조건 좋은것 아니다. 가장 적절한 time slice 찾아야!
 
🌟interrupt or system call 하나 발생시, 다른 interrupt와 system call이 실행되지 않게 OS가 mask한다.