1. PC(Program Counter)에 address를 저장하고
2. 원래의 register state를 PCB(Process Control Block)에 저장해놓아야함 | | Von Neumann architecture 폰 노이만 아키텍쳐 | 1. Instruction과 data가 같은 메모리에 올라가있고
3. 이 메모리는 CPU와 single link로 이어져있다. | | Cashe Memory 캐시 메모리 | Main Memory에서 주로 쓰이는 명령들을 기억해두는 메모리. 보통 SRAM으로 구성 | | SRAM(Static RAM) | 플립플롭으로 만들어서 전력공급이 있으면 refresh가 없어도 그 전의 상태를 그대로 기억한다. 캐시 메모리로 사용됨. | | DRAM(Dynamic RAM) | 커패시터로 만들어서 전력공급이 있어도 계속 refresh가 되어야함. 안해주면 데이터 사라짐. 메인 메모리로 사용됨. | | NVRAM | 원래 DRAM은 커패시터라서 휘발성인데 배터리 붙여서 비휘발성으로 만든 메모리. 근데 이제 배터리 안씀 | | | | | Device | 컴퓨터에 연결할 수 있는 장치 | | Device Controller | 데이터의 I/O를 책임지는 장치. CPU와 시스템 버스로 연결되어 있다. | | Device Driver | OS → Device Driver → Device controller 의 순으로 실행된다. | | | | | Asymmetric Multiprocessing 비대칭형 멀티프로세싱 | Master-slave 형태의 멀티 프로세스 구조 | | Symmetric Multiprocessing(SMP) 대칭형 멀티프로세싱 멀티 프로세서 시스템 | 프로세서(CPU)가 여러개 있고 서로 하나의 메모리를 공유함 | | Multicore System 멀티 코어 시스템 | 프로세서(CPU)가 하나만 있는데 코어가 여러개 있음. 프로세서가 하나니까 메모리도 하나. 대신 논리적으로 메모리를 배정받는다. | | Process 프로세스 | 메모리에 올라가서 실행되고 있는 프로그램의 인스턴스 (프로그램이 클래스라면 프로세스는 인스스. 여러개 생성 가능) | | | | | User mode Kernel mode | 유저가 시스템 중요한 부분에 함부로 접근하는 것을 막기위한 OS의 두가지 모드. 가벼운 명령어를 처리하는 User mode 함수와 크리티컬한 명령을 처리하는 Kernel mode 함수로 나뉜다. | | Trap | CPU 내부 interrupt. User mode ➡ Kernel mode로 전환해준다. mode bit로 현재 모드를 확인한다(user가 1, kernel이 0) | | Privileged Instructions | 시스템에 영향을 줄 수 있는 instruction. Kernel mode에서만 사용가능. 쓰고싶으면 user mode → trap → kernel mode 에서 사용하자. | | System call 시스템 콜 | user가 OS 서비스(READ/WRITE, network...)를 요청하는 일종의 API. 보통 wrapper(라이브러리)를 통해 제공된다. 이 때, portability가 보장됨. | | | | | Command line Interface (CLI) | OS Interface. User로부터 명령을 실행시킨다. Shell(sh, ksh, csh, bash)이라고도 불림. | | OS service | User Interface(CLI, GUI, batch interface) Program execution(Load, run, end, execution) I/O operation(printing, scanning...) File System Manipulation(파일,디렉토리 CRUD) Communication(프로세스간 통신) Error detection(에러 났을 때 대처) Resource allocation(컴퓨터 자원 할당) Accounting(리소스를 얼마나 쓰는지 tracking : cloud billing의 기준) Protection and Security(접근제어,보안) | | 라이브러리 → 시스템 콜 | printf, write → write fread, read → read malloc → brk | | System call 동작과정 | 1. open() system call 실행
4. PCB에 현재 레지스트리 값 저장
5. 내부 interrupt (trap) 실행. User mode → Kernel mode로 전환.
6. system calls function list에 가서 sys_open() 실행
7. return 값과 함께 다시 user mode로 돌아옴.
8. PCB에서 원래 레지스트리 가져오기.
9. 원래 Instruction 수행 | | OS Design | 설계를 할 때 매커니즘이랑 정책을 분리하자 Mechanism : How (암호화 하는 기법들 ex : SHA-256, AES, ..) Policy : What (내가 선택한 암호화 기법 ex : SHA-256) | | OS Implementation | 어셈블리어 : 빠름 but 어려움 고급언어(C언어) : 쉬움, portable(compact)함. 디버깅이 쉬움 but 느림 | | OS 구조 : Monolithic | Monolithic(모놀리식) : 하나로 다 뭉쳐져있는거 Simple Structure : 흔히 알고있는 구조. user-syscall-kernel (대부분의 OS) Layered approach

• ****OS를 몇 개의 레이어로 나눈것.
• 0(하드웨어)~M(유저)번째 레이어로 나눠져있다.
• M번째 레이어는 M-1번째 레이어를 호출
• 단순한데 레이어를 정의하기가 어렵고 효율성이 낮다. | | OS 구조 : MicroKernels | Componentized, Modularized(모듈화) : 각 기능들이 I/O와 함수로 잘 나뉘어져있는거
• 모놀리식에서는 커널이 다 열어서 return 값만 줬는데 마이크로커널은 file system에 명령만 넘겨줘서 file system application이 처리하도록 함.
• OS Kernel의 확장성이 좋고 kernel을 porting(export, import)하기 좋음
• 안전하고 가용성이 좋음
• 퍼포먼스가 낮음 | | MicroKernel‘s Functionality | 1. Inter-process Communication : 프로세스들 간 커뮤니케이션(network) 2. Memory management : 메모리 관리 3. CPU Scheduling : CPU 스케쥴링 | | Process 프로세스 | 실행되고 있는 프로그램. work의 단위. job, task등으로도 불린다. | | Process components 프로세스의 구성요소 | 현재 수행중인 Instruction : PC값 (address) 현재 순간의 Register state : 모든 register안에 있는 값 상태 Memory contents (stack, heap, 전역변수) : 메모리에 들어있는 모든 값 parent info | | Process vs Program | Program : 실행될 수 있는 파일. Passive Process : 실행되고 있는 파일. Active | | Memory space 메모리 공간 | - 물리적인 메모리가 아니라 개념상의 Virtual space이다.
• Max size는 OS에 따라 달라진다.
• 프로세스가 실행되면 4GB가 할당됨. 프로세스는 진짜 메모리인줄 앎.
• 4GB에서 1GB는 커널전용으로 분리. 3GB부분을 잘라서 사용한다. | | Memory Layout | 〓 Reserved by Kernel : 커널의 코드(system call)랑 전용 stack이 존재함 ↓ stack : stack activation record(로컬 변수, arguments, 리턴값) 영역 (stack은 아래로, heap은 위로 자라난다.) ↑ heap : dynamic memory(malloc, brk)를 요청받으면 빌려주는 영역 〓 data : 전역 변수가 선언되는 영역. 로컬 변수는 stack에 쌓인다 〓 text segment : code를 compile해서 binary code(exe)가 실행되는 영역 | | Activation record | 호출된 함수가 필요로 하는 환경에 대한 정보가 실제로 저장되는 영역 call & return : 함수의 호출과 복귀 arguments : 매개변수의 전달 local variables : 함수 내의 지역변수 처리 : Stack. Stack 최상위에는 현재 수행중인 activation record가 존재. | | Process state 프로세스 상태 | 1. New : 프로세스가 생성된 상태 2. Running : Instruction이 실행되고 있는 상태 3. Waiting : 아무것도 안하고 멈춰있는 상태. sleep 4. Ready : 프로세스가 프로세서에 할당되기를 기다리는 상태
• Schedule : 여러 프로세스가 준비되면 CPU가 차례대로 실행시키는 것
• Preemted : 한개의 프로세스만 계속 running이면 다시 ready시키는 것 5. Terminating : 프로세스가 종료된 상태. 메모리 할당 해제 전단계임. | | Process Control Block (PCB) | 프로세스의 정보를 포함하고 있는 커널의 data structure. kernel stack에 위치한다. ****포함 정보 : process state, PID, PC, register, open files, 스케쥴링 정보 등 | | | | | Process Switch 프로세스 스위치 | 이전의 process state를 보관하고 새로운 process state를 적재하는 작업. System call handling 과정과도 비슷하다. Save P0 state to PCB0 → Load P1 state from PCB1 | | Process Scheduling 프로세스 스케쥴링 | 로딩이 없도록 시간 분배를 잘 해서 다음 프로세스를 선택하는 방법.
• Multi-programming : 메모리에 프로세스가 여러 개 올라가 있는 상황
• Time-sharing : 멀티 프로그래밍의 방법 중 하나. 프로세스들 간 process switch를 빠르게 해서 사람이 interactive하게 느끼도록 함(즉각적인 반응) | | Scheduling Queue 스케쥴링 큐 | Job Queue : 컴퓨터에게 실행 할 작업을 submit (실행 x) (잘 안씀) Ready Queue : 바로 실행할 수 있는 process의 PCB들. linked list 가능 Device Queue : I/O자원(device, network)에 접근하기 위한 queue | | Scheduler 스케쥴러 | 자체적인 알고리즘(Policy)에 따라 큐에서 먼저 실행할 프로세스를 선택. Long-term scheduler : Job queue에서 고름 Short-term scheduler : Ready queue에서 고름 여러가지 기준들 : maximize CPU Utilization, average waiting time... 프로세스의 타입 : I/O-bound(I/O 많이), CPU-bound(계산 많이) | | Context 컨텍스트 | Context : PCB에 저장되어있는 Process state Context Switch : 이전의 process state를 보관하고 새로운 process state를 적재하는 작업 Process state를 PCB에 저장하지 말고 Register에 저장하자 → cpu가 복잡 | | | | | Process creation (LINUX) | fork() system call : 새로운 프로세스를 생성(복제). return value로 구분. exec() system call : 프로세스의 메모리를 날리고 새로운 프로그램 대체. wait() system call : child process가 끝날 때 까지 parent가 wait(sleep) | | Process termination | exit() system call : parent에게 state value를 return. 리소스 해제.
• parent가 child를 종료시킬 수 있다(cascading termination 계단식 종료)
• 명시적, 암시적으로 실행될 수 있다(exit()가 없어도 마지막에 호출)
• int* status; pid=wait(status); 이거 안된다.
• zombie : child process가 종료됐는데 parent가 wait으로 status 값을 못받지 child process의 pid를 제거 못하는 상태. | | | | | Pipe | Process가 communication하는 통로 | | Ordinary Pipe | 두 개의 프로세스가 producer - consumer로 단방향 통신하는 방법. fork()로 생성한다.
• fd (read-end, write-end) 상태도 복제되서 할당 해제해줘야한다.
• fork()로만 생성되서 parent-child 사이로만 만들 수 있다. | | Named Pipes (FIFO) | Bidirectional(양방향) 통신이 가능하다. Parent-child 관계가 필요없다. 하나의 OS안에서만 가능함. (Queue로 통신하는 느낌) | | Remote Procedure Calls (RPC) 원격 함수 호출 | 겉보기에는 OS 내부에서 함수를 호출하는 것 같지만 Client stub라는 미들웨어가 네트워크로 Server stub에 요청하고 return 값을 대신 받아준다. 약간 AWS Lambda느낌. 계산이 많거나 민감한 정보가 있을 때 사용한다. | | | | | Thread 쓰레드 | 실행(Execution)의 흐름이 마치 실(Thread)처럼 흘러가는 모양.
• Parallelism에 강하다. ( 1 Process+3 Thread > 3 Process+1 Thread each)
• 쓰레드를 생성하는게 간단하다. (process는 fork(), exec() 해야함)
• 리소스를 효율적으로 사용한다.
• 쓰레드들끼리 데이터를 공유하기 쉽다. (보안성은 낮음)
• Responsiveness(빠른응답), Resource Sharing, Economy, Scalability | | Multi-Thread Process 멀티스레드 프로세스 | Thread(흐름, 실행)이 여러개인 프로세스
• Instruction 실행 == register 값 사용 인데 실행이 여러개니까 register 값 또한 여러개 가지고 있어야함.
• Thread는 각각의 Register set, Stack, Program counter을 갖는다.
• code와 data, file들은 프로세스의 것으로 공유한다. | | Concurrency vs Parallelism | Concurrent : 코어 하나로 Job을 Time-sharing Parallelism : 코어 여러개에 Job을 나눠서 Time-sharing | | Hyper-Threading 하이퍼스레딩 | OS가 바라보는 Thread(실행 흐름). Process는 무시한다. CPU가 Instruction을 수행할 때 잠깐 비는 시간에 다른 Instruction을 실행시키는 것. OS 입장에서는 두 개의 흐름(Thread)가 실행되는 것 처럼 보인다. | | Multicore issue | Identifying task : 어떤 파트가 독립적인지 알아야함 (피보나치 수열) Balance : 일을 균등하게 배분해야함 Data Splitting : 데이터를 균등하게 배분해야함 Data dependency : 현재 task가 다른 task의 data에 의존함 Testing and Debugging : 실행순서가 매번 바뀜 **(Non-deterministic)
• race condition :** multi-thread(process)로 실행할 때 마다 결과가 달라짐 | | Parallelism 병렬성 | Data parallelism : 데이터를 나누는 것. range(0,n) + range(n,2n) Task parallelism : task를 나누는 것. 평균 구하기 + summary 구하기 | | Thread Level 쓰레드 종류 | 쓰레드에 대한 개념을 구체화 시켜놓은 것 User level Thread (application이 돌아가는 환경) ****- OS가 모른다. Thread가 존재하는지도 모른다.
• System call이 아닌 Library call을 사용한다. (빠름)
• 커널이 관리를 못한다. (스케쥴링 x) Kernel level Thread (kernel 내부에서 운영체제가 관리하는 환경)
• OS가 프로세스가 몇 개인지, 쓰레드가 몇 개인지 알고 있음.
• 커널이 직접 쓰레드를 스케쥴링 해준다. (유연함)
• 비교적 느리고 헤비하다. | | Multithreading Models 멀티쓰레딩 모델 | N:1 모델 : user thread 1개 → 유일한 kernel thread. 끝나면 다른 거 선택. 1:1 모델 : user thread → 전용 kernel thread 생성. Limit number. 리눅스 N:N 모델 : user thread → 임의 kernel thread 매핑. flexible but complex.
• User Thread는 Application concurrency (어플이 권장하는 쓰레드 개수)
• kernel Thread는 Physical concurrency (코어마다 concurrent) | | | | | Thread Library | 쓰레드를 만들고 관리하는 API ex) POSIX pthread, Windows thread API, JAVA thread API JAVA thread API 쓰려면 runnable()이라는 클래스가 구현되어있어야 함 | | Thread Pool | 기존 : request → 쓰레드 하나 생성. return → 쓰레드 종료 Pool : 미리 일정 갯수의 Thread를 만들어놓고 할당/해제
• 사용자 응답은 느려지는데 서버는 죽을일 없음.
• 쓰레드 생성/삭제하는데 overhead도 없어진다. | | Thread Issue | 쓰레드 하나가 fork() 할 때
• 프로세스 아래 모든 쓰레드를 복제 or 자기 자신 쓰레드만 복제
• exec하면 다 날라갈텐데 모든 쓰레드를 복제할 필요가 있을까? Signal Handling 할 때
• 어느 쓰레드한테까지 signal을 줘야하나?
• signal 받은 애 vs 모두 vs 특정 기준대로 vs signal 전용 Thread Cancellation
• 쓰레드 중에 하나가 먼저 끝나면 다른애들은 어떻게 종료시킬까?
  • Asynchronous cancellation : 즉시 취소
  • Deferred cancellation : 하는 작업만 다 끝나고 취소 (pthread) pthread_join() , pthread_testcancel() | | | | | producer-consumer problem | producer : 아이템을 생산하고 버퍼에 추가한다. consumer : 버퍼로부터 아이템을 가져오고 소비한다. producer와 consumer의 속도가 다를 때 Bounded Buffer Problem 발생 | | Race condition | 멀티프로세싱, 멀티스레딩에서 실행 순서에 따라서 결과가 달라지는 상태 | | Synchronization is Needed | Multi-thread applicatoin
• 쓰레드는 메모리를 공유하니까 더 위험함
• silent corruption : 조용하게 잘 있다가 갑자기 corrupt되는 상황 커널 모드일 때
• OS 내부의 data structure를 바꿔버릴 수 있음
• 수정에 1명보다 많은 프로세스가 참여하면 안됨
• preemptive(선점형) kernel : 기존 kernel thread를 제끼고 얘가 우선권을 잡을 수 있다. data structure 고치다가 멈추면 critical할 수 있다. | | | | | Critical-section | 공통 변수를 변경하는 코드 부분. 프로세스가 하나만 돌고 있어야 함 | | Critical-Section problem | 최대 1개의 프로세스만이 Critical-section에 접근할 수 있도록 하자. Mutual Exclusion : 하나의 Critical-section에는 하나의 process만 Progress : remainder section에 있지 않는 놈들만
• remainder에만 있는놈들 말고 고르는 즉시 action이 일어나는 놈. Bounded waiting : Critical-section에 들어갈 횟수를 제한. limit가 있음 | | Strict Alternation | 공통변수 turn을 둬서 $P_j$가 끝나면 $P_i$가 실행되도록 하자 $😶$ “나 다 끝났으니까 이제 니가 해”
• $P_i$는 $P_j$가 Critical section에서 계속 돌아야함 (Progress 위반) | | Peterson’s Algorithm | 공통변수 turn, flag써서 $P_j$가 끝나면 나갈 때 $P_i$를 while 풀어주고 나감 $😐$ “너 나 critical section 들어가기 전에 들어가지 마. 다하면 풀어줄게”
• 소프트웨어 만으로 해결했지만 두 개의 프로세스에서만 가능함

Requirement를 만족하는가?

1. Mutual Exclusion

• $P_i$는 flag[j]==false 혹은 turn==i 일때만 CS에 진입함
• 두 개 동시에 돌려면 flag[i]==flag[j]==true&&turn==i==j 이어야함

2. Progress

• flag로 나감과 동시에 상대방에 돌아가게 한다.

3. Bounded waiting

• 상대방에 끝나야 열어주니까 무조건 번갈아가면서 실행될 수 밖에 없음 | | | | | Synchronization Hardware Support | 싱글코어에서 timer inturrupt를 잠깐 stop하는거 가능 멀티코어에서는 불가능
• massage passing(프로세스간 교환)이 퍼포먼스에 영향을 미친다. 그래서 하드웨어적인 instruction을 사용한다. | | atomic instruction | instruction 1개. 스케쥴링으로 인해 더이상 쪼개질 수 없는 instruction. | | Critical-Section problem with atomic instruction | atomic instruction을 써서 Critical-Section problem 해결해보자

1. lock : Mutual-exclusion인데 빠른애만 돌 수 있음(Bounded-waiting X)
2. waiting[i] : 자기한테 가까운 애들부터 들어갈 의사가 있는지 물어봄 a. 있으면 제일 가까운 애한테 넘겨주고 자기는 나감 b. 없으면 lock을 풀고 나감. 다음에 제일 빨리 오는 애가 잠금. 자신한테 돌아온다(%n)이라는 보장이 있기때문에 Bounded-waiting | | | | | Mutex Locks mutual exclusion locks | acquire lock : available하지 않는 동안 empty loop (busy waiting) release lock : available을 true로 만들어줌 (lock을 풀어줌) busy waiting : 아무일도 안하는데 running상태임. 응답을 빨리하기 위해서 사용 (context switch가 안일어나서). 짧은 lock에서 사용하기 좋음 | | Semaphore S with busy waiting | wait(S) : S≤0일 때 busy waiting이다가 S>0이면 S-1하고 나간다. signal(S) : S+1해준다. Binary Semaphore : S가 True,False. Mutex lock이랑 똑같음 Counting Semaphore : S가 integer. n개의 프로세스를 동시에 시작 가능. 실행 순서도 조정할 수 있다. | | Semaphore S with blocking | wait(S)
3. semaphore의 (개념적인) waiting queue에 process를 넣는다.
4. ready state → wait state로 스위치 signal(S)
5. process를 wait state → ready state로 스위치
6. waiting queue에서 꺼집어내서 ready queue에 process를 넣는다. | | Deadlock, Starvation | Deadlock : 한 쪽이 wait으로 잠그면 반대쪽이 signal로 풀어줘야 하는데 둘 다 wait이라서 멈춘 상태. Starvation : blocking이 끝나지 않는 상태 (wait queue에서 못나옴). 보통 LIFO(stack)을 쓸 때 발생한다. | | busy waiting vs blocking | 짧게 기다릴거면 busy waiting 길게 기다릴거면 blocking | | Bounded-buffer Problem | 자 그럼 Bounded-buffer Problem을 어떻게 해결할 것인가.

<producer> <consumer> while : while : produce item wait(full)
wait(empty) wait(mutex) wait(mutex) remove from buffer add to buffer signal(mutex) signal(mutex) signal(empty) signal(full) consume item |