D cron

Project1: priority schedule(2) 이번엔 무엇을 바꿔볼까? 이번에는 Synchronization과 관련된 도구들의 scheduling 방식을 살펴보자. 그 도구들은 semaphore, lock, condition variables가 존재한다. 그런데 현재 PintOS는 여러 thread들이 semaphore, lock, condition variables를 얻기 위해 기다릴 경우 먼저 온 놈이 먼저 사용하는 FIFO 방식을 사용하고 있다. Synchronization 도구들을 기다릴 때, 우선순위가 가장 높은 therad가 CPU를 점유하도록 구현해보자. Semaphore 하나의 공유자원을 사용하기 위해 여러 thread가 sema_down 되어 대기하고 있다고 할 때, 이 공유자원..

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 ..