D cron

Project1: priority schedule(1) 문제 현재 PintOS는 scheduling을 어떻게 하고 있을까? 앞선 포스트에서 살펴보았듯이, 현재 PintOS는 Round-Robin방식을 채택하고 있다. 할당된 시간 4 tick이 지나면 running thread는 다른 thread에게 선점당한다. PintOS는 새로운 thread를 ready_list에 넣을 때 항상 맨 뒤에 넣는다. 그리고 ready_list에서 다음 CPU 할당할 thread를 찾을 때에는 항상 맨 앞에서 꺼낸다. 이 방식은 thread들 간의 우선순위 없이 ready_list에 들어온 순서대로 실행된다. 제대로 된 우선순위 scheduling이 이루어지지 않고 있다! 해결책 우선순위에 따라 scheduling을 하도록..

Project1: Alarm Clock PintOS에서 thread와 process의 관계 실제 OS에서는 하나의 process 안에 여러 개의 thread가 존재할 수 있으며, 이 thread들은 같은 virtual address space를 공유한다. PintOS에서는 구현을 단순화하기 위해서 하나의 process에 하나의 thread만 있도록 구성되어 있다. PintOS에 한해서는 process = thread라고 생각해도 무방하다. 실제 코드에서 pml4(특정 process의 virtual address 정보를 담고 있는 테이블)등 process가 가지고 있어야 할 내용을 thread struct가 가지고 있다. 현재 PintOS의 Alarm Clock 방식, 문제점 Alarm Clock은 자고 ..

Process Synchronization 2 Monitor 1 Semaphore의 문제점 정확성(correctness)의 입증이 어렵다. 한 번의 실수가 모든 시스템에 치명적 영향 P와 V 순서 잘못될때(왼쪽) P연산후 V를 안해줬을 때(오른쪽) monitor는 특별히 프로그래밍 언어 차원에서 Synchronization 문제를 해결하기 때문에 high-level synchronization construct라고 한다. 공유데이터를 접근하기 위해서는 내부의 procedure를 통해서만 접근가능하게 만듬 Monitor 2 프로그래머 입장에서는 뭐가 편할까? lock을 걸 필요가 없다. 기본적으로 monitor에 대한 동시접근을 허용하지 않는다. 나머지 프로세스는 기다려야 함(monitor가 자동으로 해결..

Process Synchronization 1 데이터의 접근 data가 있는 위치에서 읽어와서 연산을 수행하고 다시 그 위치에 연산결과를 저장한다. data를 읽기만 하면 문제가 없다. 하지만, data를 읽어서 수정을 하고 결과를 저장하는 방식에서는 누가 먼저 읽어갔는지에 따라 결과가 달라질 수 있다. Race Condition 여러 주체가 하나의 data를 동시에 접근하려고 할 때 race condition이 발생할 수 있다. → 조율해주는 방식이 필요하다. OS에서 race condition은 언제 발생하는가? 프로세스간에서는 자원을 공유하지 않기 때문에 보통 발생하지 않는다(User mode에서는 별로 안생김). Kernel 수행 중 인터럽트 발생 시 Process가 system call을 해서 ..

CPU Scheduling 2 Multilevel Queue Ready queue를 여러 개로 분할 foreground(interactive) background(batch - no human interaction) 각 큐는 독립적인 스케줄링 알고리즘을 가짐 foreground - RR(Round Robin) background - FCFS 응답시간이 빠르다고 좋을게 없다. 어짜피 사람이랑 소통 x context switch overhead를 줄이기 위해 FCFS를 사용하는 것도 방법 큐에 대한 스케줄링 필요 Fixed priority scheduling serve all from foreground then from background starvation 가능성 존재 Time slice 각 큐에 CPU..

CPU Scheduling 1 CPU and I/O Bursts in Program Execution CPU burst : CPU를 연속적으로 쓰는 단계 I/O burst : I/O를 실행하는 단계 CPU-burst Time의 분포 CPU는 실제로는 CPU bound job이 많이 사용하는데 그 빈도수가 적은 것이고, I/O bound job은 CPU를 짧게 쓰는데 빈도가 잦은 것이다. 여러 종류의 job(=process)이 섞여 있기 때문에 CPU 스케줄링이 필요하다. 사람과 소통하는 I/O bound job에 CPU를 우선적으로 준다. 프로세스의 특성 분류 프로세스는 그 특성에 따라 2가지로 나눈다. I/O bound process CPU를 잡고 계산하는 시간보다 I/O에 많은 시간이 필요한 job ..

Process Management 프로세스 생성(Process Creation) 부모 프로세스(parent process)가 자식 프로세스(child process)를 생성 자식이 부모를 복제함 프로세스의 문맥을 모두 복제 자식은 그 공간에 새로운 프로그램을 올림 유닉스의 예시 fork() 라는 system call이 새로운 프로세스 생성 fork() 후에 exec()이라는 system call로 새로운 프로그램을 메모리에 올림 계층구조는 트리 형식이 됨 부모와 자식은 독립적으로 자원을 전혀 공유하지 않는다(일반적으로). advanced 된 내용으로 COW(copy-on-write)를 사용하면 공유할수도 있음 write가 발생할 때(내용이 바뀔 때) copy하겠다는 내용도 있음 수행 부모와 자식이 공존하..