Operating System 12주차 - Process Synchronization (1)-

Presentation on theme: "Operating System 12주차 - Process Synchronization (1)-"— Presentation transcript:

1 Operating System 12주차 - Process Synchronization (1)-
Real-Time Computing and Communications Lab. Hanyang University

2 Contents Process Synchronization Mutex Semaphore
Readers-Writers Problem 과제 #6

3 Process Synchronization
데이터의 일관성을 위해 shared data에 대한 동시 접근을 제어하는 것 일관성을 유지하기 위해서는 관련된 프로세스들이 순차적으로 실행되는 보장하는 방법이 요구됨

4 The Critical-Section Problem
N개의 프로세스들은 서로 shared data를 사용하기 위해 경쟁한다. shared data에 접근하는 코드 부분을 critical section이라고 한다. critical section 은 한번에 하나의 프로세스만 접근 가능하다.

5 The Critical-Section Problem
각각의 프로세스들은 동기화를 위해 사용하기 위한 변수를 공유한다. General process Pi entry section : critical section에 들어가기 위한 요청을 수행 exit section : critical section의 수 행이 끝난 후 출구 부분 remainder section : 코드의 나머 지 부분

6 Mutex Critical section으로 들어가기 위한 하나의 키.

7 Mutex Mutex mechanism

8 Mutex functions Header File : pthread.h Mutex 초기화 Mutex lock
int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutexattr); mutex : 초기화할 mutex의 pointer mutexattr : mutex의 특성을 설정할 때 사용 (사용하지 않을 경우 NULL) Mutex lock int pthread_mutex_lock(pthread_mutex_t *mutex); Mutex unlock int pthread_mutex_unlock(pthread_mutex_t *mutex); Mutex 제거 int pthread_mutex_destory(pthread_mutex_t *mutex); 사용하고 난 뒤 mutex와 resource 해제 모든 함수는 성공 시 0을 return

9 Mutex Example

10 Mutex pthread compilation gcc command에서 맨 뒤에 -lpthread 옵션을 추가

11 Mutex Example 결과

12 Semaphore Mutex와 같이 critical section에 대한 접근을 제한하는 키로 활용됨
integer variable S를 가지며, 2개의 atomic operation을 통해 접근 제어가 수행됨 P(S) : wait function V(S) : signal function

13 Semaphore functions Header file : semaphore.h Semaphore 초기화
int sem_init(sem_t *sem, int pshared, unsigned int value); sem : 초기화할 semaphore 객체 pshared : 0이 아니면 프로세스들 간에 semaphore를 공유. 0이면 프로세스 내부에서만 semaphore를 사용 value : semaphore 초기값 Semaphore value 감소 int sem_wait(sem_t *sem); int sem_trywait(sem_t *sem); sem_wait : semaphore 값이 0보다 크면 프로세스는 semaphore를 얻은 뒤 감소시키고 즉시 리턴값을 반환한다. semaphore 값이 0이면 0보다 커지거나 signal이 발생할 때까지 대기한다. sem_trywait : sem_wait과 기본적으로 같지만, 즉시 semaphore를 감소시키고 리턴값을 반환한다는 점이 다르다.

14 Semaphore functions Semaphore value 증가 Semaphore value 저장 Semaphore 삭제
int sem_post(sem_t *sem); Semaphore value 저장 int sem_getvalue(sem_t *sem, int *sval); sval이 가리키는 위치에 sem의 현재값을 저장 Semaphore 삭제 int sem_destory(sem_t *sem); semaphore를 포함해 관련된 resource를 모두 해제

15 Semaphore Example

16 Semaphore Example

17 Semaphore Example 결과

18 Classical Problems of Synchronization
Readers and Writers Problem First problem – give preferential treatment to readers Second problem – give preferential treatment to writers Third problem – give neither priority The Dining – Philosophers Problem Example of concurrency-control problem

19 Readers-Writers Problem
하나의 저장공간을 여러 명의 독자와 저자들이 접근할 때 발생하는 문제이며 크게 2가지 문제로 나눌 수 있다. First Readers-Writers Problem Second Readers-Writers Problem 독자는(Readers) 저장공간에서 데이터를 읽어오기만 한다. 저자는(Writers) 저장공간에 데이터를 기록한다. Shared Memory Writer Reader

20 First Readers-Writers Problem
기본적으로 프로세스의 동기화를 위해서 같은 저장공간에 2개 이상의 프로세스가 동시에 접근하는 것을 막는다. 하지만 독자(Readers)는 데이터를 읽어오기만 하므로, 동시에 여러 명의 독자가 접근하는 것을 막는 행위는 어리석은 짓이다. 이에 대한 문제 해결한 것을 First Readers-Writers Problem 혹은 Readers-Preference 라고 한다. Shared Memory Writer Reader[1] Reader[2] Reader[N] … 우리들도 같이 읽을래!

21 First Readers-Writers Problem
{ wait(wrt); // writing // (Critical Section Area) signal(wrt); } Shared Data semaphore wrt = 1, mutex = 1; int readcount = 0; 첫 번째 독자가 저자가 접근 못하게 잠근다. 마지막 독자가 다시 접근 가능하게 풀어준다. reader() wait(mutex); readcount++; if(readcont == 1) signal(mutex); // reading readcount--; if(readcount == 0) 1. 2.

22 Second Readers-Writers Problem
First Readers-Writers Problem에서 다수의 독자가 존재하거나, 소수의 독자가 지속적으로 공유 메모리에 접근함으로써 새롭게 접근한 저자가 “resource starvation”에 처할 수 있다. 이에 대한 문제 해결한 것을 Second Readers-Writers Problem 혹은 Writers-Preference 라고 한다. 독자들이 계속 접근해난 언제까지 기다려? Reader[1] Writer[1] Shared Memory Reader[2] Writer[2] … Reader[N]

23 Second Readers-Writers Problem
Shared Data semaphore mutex_rdcnt = 1, mutex_wrcnt = 1; semaphore mutex_check = 1; semaphore w = 1, r = 1; int readcount = 0, writecount = 0; writer() { wait(mutex_wrcnt); writecount++; if(writecount == 1) wait(r); signal(mutex_wrcnt); wait(w); // writing // (Critical Section Area) signal(w); writecount--; if(writecount == 0) signal(r); } 새로운 저자가 접근을 시도하면 독자가 접근 못하게 잠근다. 마지막 저자가 다시 풀어준다. reader() wait(mutex_check); wait(mutex_rdcnt); readcount++; if(readcont == 1) signal(mutex_rdcnt); signal(mutex_check); // reading readcount--; if(readcount == 0) 1. 2.

24 과제 #6 1. 앞에서 배운 Shared Memory에 대하여, Second Readers-Writers Problem을 해결하는 Lock, Unlock System call을 구현한다. 2. System call은 세마포어를 이용하여 구현한다. 3. 유저레벨에서 만든 shared memory에 대해서 동작하며, 이를 위해 shmid를 인수로 받아온다. printk를 이용해 커널버퍼에 현재 상태를 기록함으로써, 동기화 여부를 판단할 수 있도록 한다. sleep 함수 등을 이용하여, 적당한 딜레이를 주어 다음 슬라이드에 확인해야 할 3가지 상황에 대한 측정을 용이하게 할 수 있도록 한다.

25 과제 #6 4. 구현한 시스템 콜을 이용하여 Reader, Writer 프로그램을 구현한다. 5. Test
Writer는 SIGINT(ctrl+c)신호를 받으면 유저로부터 문자열을 입력 받아 데이터를 공유메모리에 기록하고, SIGTSTP(ctrl+z)가 있을 때까지 프로그램을 종료하지 않고 대기한다. Reader는 SIGTSTP(ctrl+z)이 있을 때까지, 계속해서 데이터를 읽어온다. IPC 실습 PPT + signal 사용법 참고. 5. Test 각각의 터미널에서 프로그램을 실행한다. 이때 커널메시지를 확인하기 위해 사전에 $sudo dmesg --clear 를 입력한다. 아래의 항목들을 확인하고, 캡쳐한 뒤 분석한다. (1) 2명의 저자가 동시에 접근 불가한 것을 확인할 수 있어야 한다. (2) 2명 이상의 독자가 동시에 접근 가능한 것을 확인할 수 있어야 한다. (3) 저자에게 우선권이 있음을 확인할 수 있어야 한다. (writers-preference)

26 과제 #6 Example> (1) 2명의 저자 동시접근 불가능!
위에서 2500, 2501은 해당 writer process의 pid를 의미한다. Writer[2500]이 Unlock 한 뒤, Writer[2051]이 Write Start를 시작하는 것을 확인할 수 있다. 즉, 복수의 저자의 접근을 방지한다. 2명의 저자 동시접근 불가능!

27 과제 #6 Example> (2) 3명의 Reader 3353, 3354, 3355가 존재하고, Read End에 상관없이 동시에 공유메모리에 정보를 읽는 것을 확인할 수 있다. 복수의 Reader가 접근가능

28 과제 #6 Example> (3) 진행중인 Reader가 끝나면, 즉시 기다리고 있던 Writer가 실행
기존의 동작하던 3개의 Reader Process가 Read를 끝낸 뒤 다시 Read하지 않고, 기다리고 있는 Write Process에게 우선권을 주는 것을 확인할 수 있다. First readers-writers problem 에 대해서 구현하게 되면, 다수의 Reader Process가 계속해서 접근할 경우 resource starvation 으로 인해, Writer Process가 계속해서 실행되지 않을 수 있다. 진행중인 Reader가 끝나면, 즉시 기다리고 있던 Writer가 실행 (Writer-Preference)

29 과제 #6 Due : 2015/06/05 실습 수업 시간 6/5 실습 보고서 출력해서 수업시간에 제출 보고서
표지 과제 내용 요약 전체적인 과제 구현 과정(시스템 콜, 유저레벨 프로그램, 커널코드 수정 등…) 최종 결과 및 분석 (앞에 3가지 경우에 대한 스크린샷과 분석) 후기 6/5 실습수업 강의 후 프로그램 동작 확인 결석해야 할 사유가 있을 시 사전에 조교에게 말할 것. 지연제출에 대해서는 개별적으로 조교에게 연락해서 확인 받을 것! 보고서 및 프로그램 확인 전부 받아야 과제 점수 인정.

30 과제 #6 문의사항 지연제출에 대해서는 감점이 있을 수 있음. 이름 : 김연준
이름 : 하태욱 실습관련 질문 시 제목을 아래의 양식에 맞춰서 메일을 보내주세요. ex> [운영체제] 학번_이름 지연제출에 대해서는 감점이 있을 수 있음.