Synchronization.

Presentation on theme: "Synchronization."— Presentation transcript:

1 Synchronization

2 목 차 Concurrency Critical Section Software Solution Hardware Solution
Synchronization 목 차 Concurrency Critical Section Race Condition, Mutual Exclusion Software Solution Hardware Solution Test-And-Set (TS), Swap OS Solution Event, Signal Semaphores, Monitors, Message Passing UNIX Pipe

3 Monitors Monitor란? Language에서 동기화를 제공하는 추상화 데이터 타입(ADT)
Definition of Monitors Monitors Monitor란? Language에서 동기화를 제공하는 추상화 데이터 타입(ADT) 개념적으로 동기적인 접근이 필요한 데이터와 데이터에 접근하는 Critical Section을 포함한 함수로 구성. 한번에 단지 하나의 프로세스만이 Monitor에서 함수를 수행 monitor anADT { semaphore mutex = 1; // Implicit . . . public: proc_i(…) { P(mutex); // Implicit <processing for proc_i>; V(mutex); // Implicit };

4 Monitors (Cont’d) 모니터 동작 특징: 상호배제(Mutual exclusion)를 보장
지역 변수는 모니터 내의 함수(프로시저)에 의해서만 접근 가능 프로세스는 모니터의 프로시저 호출을 통해 모니터에 진입 가능 언제나 단지 하나의 프로세스만이 모니터 내부에 존재 상호배제(Mutual exclusion)를 보장 상호배제를 위하여 별도의 프로그램을 작성할 필요 없음 운영체제에서 제공 공유 데이터 또는 자원을 모니터 안에 둠으로써 보호 공유 자원을 Monitor 내부에 지역 변수로 정의

5 Monitors (Cont’d) High-Level Language Support . . .
Concept of Monitors Monitors (Cont’d) Process Waiting Queue shared data High-Level Language Support Monitor 자원 사용은 상위 언어에서만 지원 가능 Queue에 대기하고 있는 Process 만이 모니터 객체의 data, operation에 차례대로 접근가능 공유 자원의 동시 접근을 완전히 해결 . . . operations initialization code Instance of Monitor Class

6 Monitors (Cont’d) Monitor 예제
Monitor Solution of Shared Value Monitors (Cont’d) Monitor 예제 balance변수를 조작하는 함수는 monitor 내에 있으므로 하나의 프로세스만이 balance변수 조작 가능. monitor sharedBalance { double balance; public: credit(double amount) {balance += amount;}; debit(double amount) {balance -= amount;}; . . . };

7 Monitors (Cont’d) Monitor의 선언과 수행 (Reader/Writer에 Monitor 적용 예제)
Monitor Solution of Readers-Writers Case 1 Monitors (Cont’d) Monitor의 선언과 수행 (Reader/Writer에 Monitor 적용 예제) 보통의 객체 지향 언어의 사용과 동일한 형태. 협력하는 프로세스의 기본 조건을 만족. Monitor 선언 코드 Monitor 실행 코드 monitor readerWriter_1 { int numberOfReaders = 0; int numberOfWriters = 0; boolean busy = FALSE; public: startRead() { }; finishRead() { startWrite() { finishWrite() { reader(){ while(TRUE) { . . . startRead(); read the resource; finishRead(); } fork(reader, 0); fork(reader, 0): fork(writer, 0); writer(){ while(TRUE) { . . . startWriter(); write the resource; finishWriter(); }

8 Monitors (Cont’d) 모니터에서 발생 가능한 문제점 Monitor Problem of Readers-Writers
시나리오 1. Reader가 대기 큐에 도착 2. Writer가 대기 큐에 도착 문제점: finishRead()를 수행하지 못함 (startWrite가 수행하면서 Monitor을 점유하고 있기 때문이다.) monitor readerWriter_1 { int numberOfReaders = 0; // 현재 도착한 Reader의 개수 int numberOfWriters = 0; // 현재 도착한 Writer의 개수 boolean busy = FALSE; // 현재 쓰고 있는 Writer public: startRead() { while(numberOfWriters != 0) ; numberOfReaders++; }; finishRead() { numberOfReaders--; }; startWrite() { numberOfWriters++; while( busy || (numberOfReaders > 0) ) ; busy = TRUE; }; finishWrite() { numberOfWriters--; busy = FALSE; }; }; 한번에 하나의 process/threads만 동작 가능한 Monitor 내부에 조건을 만족하지 못하는 while();이 수행되면, 하나의 process/threads가 지속적인 수행을 하게 되어 다른 Process의 진행이 불가능 함.

9 Monitors (Cont’d) 모니터에서 빠져 나오기 위해 잠시 멈추는(Suspend) 방법이 필요
Problem of Monitor Monitors (Cont’d) 모니터에서 빠져 나오기 위해 잠시 멈추는(Suspend) 방법이 필요 프로세스/스레드는 condition이 바뀔 때까지 대기 numberOfReader가 0이 될때까지 대기 condition이 바뀔 때 재 시작할 수 있는 특별한 메커니즘 필요 프로세스는 condition이 만족하지 않을 때, Monitor를 빠져나가 suspend 됨 다른 프로세스가 condition을 변경할 때 Suspend된 프로세스가 깨어나고 Monitor에 진입 Condition Variable

10 Monitors (Cont’d) Condition Variables을 이용하여 해결.
Solution of Monitor Problem Monitors (Cont’d) Condition Variables을 이용하여 해결. 일종의 OS 제공 event임 모니터 내부에서만 발생(event는 모든 프로세스/스레드에 영향을 주지만 Condition Variables은 모니터 내부에만 영향을 준다.) Condition Variable을 다루는 Operations wait: Suspend (다른 프로세스가 signal을 수행하기 전까지 일시적으로 중지된 프로세스) signal: 하나라도 일시 중지된 프로세스가 있으면 이를 재개하도록 한다. 없으면 아무것도 하지 않음. queue: 적어도 하나의 일시 중지된 프로세스가 존재하면 TRUE를 반환.

11 Monitors (Cont’d) Reader/Writer 예제 ex) R→W→R signal signal signal
Monitor Solution of Readers-Writers Case 2 Monitors (Cont’d) Reader/Writer 예제 ex) R→W→R monitor readerWriter_2 { int numberOfReaders = 0; boolean busy = FALSE; condition okToRead, okToWrite; // numberOfReaders == 기다리는 reader의 수, busy == 현재 writer중임을 밝힘, okToRead == public: startRead() { if(busy || (okToWrite.queue()) okToRead.wait(); numberOfReaders++; okToRead.signal(); }; finishRead() { numberOfReaders--; if(numberOfReaders == 0) okToWrite.signal(); }; startWrite() { if((numberOfReaders != 0) || busy) okToWrite.wait(); busy = TRUE; }; finishWrite() { busy = FALSE; if(okToRead.queue()) okToRead.signal(); else }; StartRead는 대기하고 있는 모든 Reader에게 시그널 전송 (Reader는 동시에 여러 개 수행가능) Ex의 첫 reader는 okToReader에서 대기 signal FinishRead는 모든 Reader가 작업 종료 시, Writer에게 시그널 전송 Ex의 writer은 okToWrite에서 대기 signal signal FinishWrite는 대기하고 있는 Reader와 Writer에게 시그널 전송 (Reader에게 우선순위 부여) signal

12 Signal Semantics Hoare semantics Hansen semantics(Mesa 언어에서 구현)
Two Types of Monitor Semantics Signal Semantics Hoare semantics suspend(P1) signal(P0): Signal이 발생하면 P0는 멈추고 P1이 if문 다음부터 실행 . . . if(resourceNotAvailable()) resourceCondition.wait(); /* now available … continue … */ resourceCondition.signal(); Hansen semantics(Mesa 언어에서 구현) suspend(P1) signal(P0): P0는 Signal을 발생만 시키고, 실행을 계속하고 끝낸 후에 P1의 조건을 다시 검사 while(resourceNotAvailable()) resourceCondition.wait(); /* now available … continue … */ resourceCondition.signal();

13 Monitors의 예 문제정의 한 방향(One way) 터널이 존재 반대편에 차량이 없는 경우에만 터널 사용 가능
Monitor Example of Traffic Problem Monitors의 예 문제정의 한 방향(One way) 터널이 존재 반대편에 차량이 없는 경우에만 터널 사용 가능 현재 진행중인 방향에 도착하면 터널을 바로 사용 가능 North N N S N 차량: Process Condition Queue: 1개 터널을 지나갈 수 없음 S One-way tunnel S S S 터널을 지나갈 수 있음 X 터널을 지나갈 수 있음 터널을 지나갈 수 없음 South S

14 Monitors의 예(Cont’d) 편도 터널 해결 방법 차량이 도착하면 반대 방향 차량이 있는가로 진행 여부 판단
현재 이동 가능한 방향은 모든 차량이 지날 때까지 계속 유지됨. 편도 터널 선언 코드 편도 터널 실행 코드 monitor tunnel { int northbound = 0; int southbound = 0; trafficSignal nbSignal = RED; trafficSignal sbSignal = GREEN; condition busy; public: northboundArrival() { }; southboundArrival() { depart(Direction exit) { NorthCar(){ while(TRUE) { . . . northboundArrival(); depart(NORTH); } fork(NorthCar, 0); fork(SouthCar, 0): fork(SouthCar, 0); SouthCar(){ while(TRUE) { . . . southboundArrival(); depart(SOUTH); }

15 Monitors의 예(Cont’d) 편도 터널의 해결 방법 Signal Signal
Monitor Solution of Traffic Problem Monitors의 예(Cont’d) 편도 터널의 해결 방법 monitor tunnel { int northbound = 0, southbound = 0; trafficSignal nbSignal = RED, sbSignal = GREEN; condition busy; public: northboundArrival() { if(southbound > 0) busy.wait(); northbound++; nbSignal = GREEN; sbSignal = RED; }; southboundArrival() { if(northbound > 0) busy.wait(); southbound++; nbSignal = RED; sbSignal = GREEN; }; depart(Direction exit) { if(exit = NORTH) { northbound--; if(northbound == 0) while(busy.queue()) busy.signal(); }; else if(exit == SOUTH) { southbound--; if(southbound == 0) while(busy.queue()) busy.signal(); } }; } 수행 내용 북쪽터널 입구에 도착한 경우 - 남쪽에 차량이 있다면 대기. - 차량이 없다면 Shared Value 변경 - 신호등 변경. 남쪽터널 입구에 도착한 경우 - 북쪽에 차량이 있다면 대기. 북쪽에서 출발하여 남쪽에 도착한 경우 - Shared Value 변경 - 북쪽에 남아있는 차량 수를 확인. : 남아있다면 현재 신호등 유지 : 없다면 남쪽에 대기하는 차량에 signal 전송 남쪽에서 출발하여 북쪽에 도착한 경우 - 남쪽에 남아있는 차량 수를 확인. : 없다면 북쪽에 대기하는 차량에 signal 전송 1 2 3 4 1 Signal 2 Signal 3 4

16 Monitors의 예(Cont’d) 생각하는 철학자 문제 5명의 철학자와 5개의 포크 철학자들은 오직 먹거나 생각만 함
먹기 위해서는 좌/우 양쪽의 포크가 반드시 필요 아무도 먹지 못하여 굶어 죽지 않아야 함 서로 아무것도 못하는 상태가 되지 않아야 함

17 Monitors의 예(Cont’d) Thinking i 먹으려고 할때 p2 Thinking or Eating Thinking
Monitor Solution of Dining Philosophers Monitors의 예(Cont’d) Thinking i If i = 0: test p4, p1 (0 – 1) mod 5 = 4 (0 + 1) mod 5 = 1 If i = 1: test p0, p2 (1 – 1) mod 5 = 0 (1 + 1) mod 5 = 2 If i = 2: test p1, p3 (2 - 1) mod 5 = 1 (2 + 1) mod 5 = 3  p2, p3을 test함. If i =3: test p2, p4 (3 - 1) mod 5 = 2 (3 + 1) mod 5 = 4 If i = 4: test p3, p0 (4 – 1) mod 5 = 3 (4 + 1) mod 5 = 0 Test한 철학자가 EATING이 아니면 fork를 사용할 수 있음. 먹으려고 할때 test((i-1) mod n) test((i+1) mod n) p2 Thinking or Eating Thinking or Eating p1 p3 p0 p4 n : 철학자의 수 i : 식사를 하려는 철학자

18 Monitors의 예(Cont’d) 생각하는 철학자 해결 방법 식사하려는 철학자 좌우 철학자가 생각 중이면 식사 가능
식사가 끝나면 좌우 철학자가 식사할 수 있도록 해준다. 생각하는 철학자 선언 코드 생각하는 철학자 실행 코드 monitor diningPhilosophers { status state[N]; condition self[N]; test(int i) public: diningPhilosophers() { }; pickUpForks(int i) { putDownForks(int i) { Philosophers(){ while(TRUE) { . . . pickUpForks(i); putDownForks(i); } fork(Philosophers, 0); fork(Philosophers, 0):

19 Monitors의 예(Cont’d) 생각하는 철학자 해결 방법 Signal
Monitor Solution of Dining Philosophers Monitors의 예(Cont’d) 생각하는 철학자 해결 방법 #define N ___ enum status(EATING, HUNGRY, THINKING}; monitor diningPhilosophers { status state[N]; condition self[N]; test(int i) { if((state[(i-1) mod N] != EATING) && (state[i] == HUNGRY) && (state[(i+1) mod N] != EATING)) { state[i] = EATING; self[i].signal(); } }; public: diningPhilosophers() { // Initilization for(int i = 0; i < N; i++) state[i] = THINKING; }; pickUpForks(int i) { state[i] = HUNGRY; test(i); if(state[i] != EATING) self[i].wait(); }; putDownForks(int i) { state[i] = THINKING; test((i-1) mod N); test((i+1) mod N); }; } Signal 식사하려는 철학자 좌우의 철학자 상태를 점검하고, 식사가 가능하면 시그널을 전송한다. 철학자 초기화. 모두 생각하는 상태. PickUpForks: 상태 변경. 좌우 철학자 확인. 현재 식사 중이 아니면 대기 putDownForks: 상태 변경. 좌우 철학자가 식사하려고 하면 식사할 수 있도록 한다.

20 Events Event란? Event의 처리 방법 Windows OS가 발생시키는 소프트웨어적인 condition
Event Mechanism Supported by OS Events Event란? Windows OS가 발생시키는 소프트웨어적인 condition 세마포어 추상화 -> 신호 주고(V) 받기(P)에 유용 Event Descriptor: Blocked Process List를 저장하고 있음 세마포어와의 차이점: Signal이 “no effect”일 때도 있음 Event의 처리 방법 하나의 프로세스는 다른 프로세스가 시그널을 보낼 때까지 대기할 수 있음( 예, ① ) 시그널이 발생할 때, 대기 중인 프로세스는 unblock됨( 예, ③ ) 시그널을 기다리지 않는 프로세스는 그 시그널을 무시함 queue function이 시그널을 기다리는 프로세스의 개수를 return함( 예, ④ )

21 Events (Cont’d) Events 예제 1 3 4 2 Resume Process i wait() Process j
Flow of Events Events (Cont’d) Events 예제 class Event { shared Event topOfHour; public: void signal(); void wait() int queue(); } Process i 정각이 될때(Event)까지 대기 . . . // Wait until the top of the hour before proceeding topOfHour.wait(); // It’s the top of the hour ... wait() 1 Process j 정각이 되면 Event를 대기(큐에 저장되어 있는) 하는 프로세스가 없을 때까지 Event를 발생한다. Resume 3 . . . while(TRUE) if(isTopOfHour()) while(topOfHour.queue() > 0) topOfHour.signal(); } 4 topOfHour signal() 2

22 UNIX Signals Signal은 일종의 event임 특징 UNIX 시그널의 예
Signal Mechanism Supported by OS UNIX Signals Signal은 일종의 event임 UNIX OS가 발생시키는 소프트웨어적인 condition 특징 Signal은 인터럽트 스타일의 handler를 쉽게 작성할 수 있게 해줌 UNIX 시그널의 예 사용자의 “Control + C” 입력 0으로 숫자를 나누려는 연산 존재하지 않는 파이프에 입력하려는 시도 etc.

23 UNIX Signals (cont’d) UNIX는 버전에 따라 고정된 개수의 Signal 집합을 가짐
Characteristic of Signal UNIX Signals (cont’d) UNIX는 버전에 따라 고정된 개수의 Signal 집합을 가짐 signal.h 에 OS가 사용할 수 있는 Signal이 정의됨 사용자 정의 시그널 정의 SIGUSR1 & SIGUSR2 사용 kill(pid, signal); 시스템호출을 이용하여 시그널 발생 pid : Signal을 전송하려는 프로세스 ID signal : 전송하려는 정의된 Signal 혹은 사용자 정의 Signal

24 UNIX Signals (cont’d) 시그널 처리의 세가지 방법
Kernel의 default handler가 Signal 처리 signal(SIG#, SIG_DFL) 프로그래머가 정의한 handler가 Signal 처리 signal(SIG#, myHandler) Signal 무시 signal(SIG#, SIG_IGN)

25 UNIX Signals (cont’d) Signal Handling /* code for process p */ . . .
Process Flow of Signal and Handler UNIX Signals (cont’d) Signal Handling /* code for process p */ . . . signal(SIG#, sig_hndlr); /* ARBITRARY CODE */ void sig_hndlr(...) { } 실행 중인 프로세스, p 시그널 “SIG#” 발생 시그널 handler “sig_hndlr” 를 p의 address space에서 실행 p 는 block 프로세스 p 실행 재개

26 UNIX Signals (cont’d) ▶ 자식 프로세스 루틴 ▶ 부모 프로세스 루틴
Example Code of Signal - 1 UNIX Signals (cont’d) #include <signal.h> static void sig_handler(int); int main () { int parent_pid, child_pid, status; if(signal(SIGUSR1, sig_handler) == SIG_ERR) printf(“Parent: Unable to create handler for SIGUSR1\n”); if(signal(SIGUSR2, sig_handler) == SIG_ERR) printf(“Parent: Unable to create handler for SIGUSR2\n”); parent_pid = getpid(); if((child_pid = fork()) == 0) { child_pid = getpid(); printf(“Child pid: %d\n”, child_pid); kill(parent_pid, SIGUSR1); for (;;) pause(); } else { printf(“Parent pid: %d\n”, parent_pid); kill(child_pid, SIGUSR2); pause(); printf(“Parent: Terminating child … \n”); kill(child_pid, SIGTERM); wait(&status); printf(“done\n”); ▶ 자식 프로세스 루틴 1. 부모 프로세스 에게 SIGUSR1시그널을 보냄 2. 시그널이 발생할 때 까지 대기 ▶ 부모 프로세스 루틴 1. 자식 프로세스에게 SIGUSR2시그널을 보냄 2. 자식에게 종료시그널(SIGTERM)을 보냄 3. 자식이 종료할 때까지 대기함

27 Unix Signal (cont’d) 수행 결과화면 시그널 handler
Example Code of Signal - 2 Unix Signal (cont’d) static void sig_handler(int signo) { switch(signo) { int cur_pid = getpid(); case SIGUSR1: /* Incoming SIGUSR1 */ printf(“Parent: Received SIGUSER1 (pid: %d)\n”, cur_pid); break; case SIGUSR2: /* Incoming SIGUSR2 */ printf(“Child: Received SIGUSER2\n” (pid: %d)\n”, cur_pid); default: break; } return; 시그널 handler 수행 결과화면

28 IPC (Inter-Process Communication)
Definition of IPC IPC (Inter-Process Communication) IPC 란? 프로세스간 정보전달을 위해서 Message를 사용하는 메커니즘 IPC의 필요성 각각의 쓰레드나 프로세스는 동기적인(또는 비동기적인) 공동 작업을 하기 위해 상호간에 정보전달을 할 필요가 있음 Signal, semaphore 등은 하나의 프로세스에서 다른 프로세스로 정보를 전달할 수 없음 Monitor는 정보를 공유하나, Monitor 내의 shared memory를 통해서만 가능. Shared Memory로 프로세스간 의사소통을 할 수 없는 경우 방법은 IPC 밖에 없다. OS가 Shared Memory를 지원하지 않을 경우 프로세스가 네트워크 상의 서로 다른 Machine에 존재할 경우

29 IPC (Cont’d) Basic Mechanism 다양한 IPC 방법들이 존재.
Basic Mechanism of IPC IPC (Cont’d) Basic Mechanism p0가 p1에게 정보를 복사하려면 Memory protection을 우회할 필요가 있음 원격지에 정보를 복사하기 위해 네트워크를 사용해야 함 다양한 IPC 방법들이 존재. Mailbox, Message Queue, Shared Memory ETC.. 공유될 정보 복사된 Message OS IPC Mechanism Address Space for p0 Address Space for p1

30 Message Format Message Header와 Body로 구성 Control information:
버퍼 용량을 벗어날 경우(Overflow) 처리. 메시지 순서 번호 우선순위 등. Message Type Destination ID Header Source ID Message Length Control Information Message Contents Body

31 Message Protocols 필요성 Message system은 protocol을 명세함
Needs of Message Protocols Message Protocols 필요성 Message를 주고 받는 각 Process가 서로에 대해 알아야 전송 및 수신이 가능. Sender는 receiver가 ready상태인지 또는 sender가 보낸 정보를 receiver가 수신했는지를 알아야 함 Message system은 protocol을 명세함 Message의 전송과 수신 시에 공통된 형태가 필요하고, receiver는 sender가 보낸 정보를 해석할 수 있어야 함 Standard header가 필요. <sys/msg.h> Message Queue <sys/sem.h> Semaphore <sys/shm.h> Shared Memory

32 Message Protocols (Cont’d)
Two Message Transmit Methods Message Protocols (Cont’d) Transmit Operations 각각의 전송방법은 receiver에게 Message를 전달함 Asynchronous Send Message 전송 후, 코드를 계속 실행. Receiver로부터 정보가 전달되었다는 feedback이 없음 장점: 전송 후에 다른 작업 처리 가능. 단점: 정상 전송이 되었는지 알 수 없음. Synchronous send Message 전송 후, 메시지를 받을 때까지 sender는 block됨 장점: Message의 정상처리와 오류제어를 할 수 있음. 단점: Message를 받을 때까지 불특정 시간을 대기해야 함. Message를 mailbox에 전달하고, sender는 실행을 재개 실제로 receiver가 mailbox에서 꺼낼 때 실행을 재개 동기화

33 Message Protocols (Cont’d)
Two Message Receive Methods Message Protocols (Cont’d) Receive Operation 각각의 수신 방법은 Message를 가져 옴. Blocking receive: Mailbox에 Message가 없다면, receiver는 Message가 도착할 때가지 block 장점: 정확한 Message의 수신가능. (오류제어) 단점: 전송 수단의 문제 발생시 불특정 시간 동안 대기해야 함. Nonblocking receive: Mailbox에 Message가 없다면, 이 상황에 대한 error값 반환 Blocking가 없다. 장점: Process는 지속적으로 작업 가능. 단점: Message가 도착하지 못한 경우 처리 불가능 상태가 됨.

34 Message Protocols (Cont’d)
Message Send Using Synchronized Transmit and Block Receive Message Protocols (Cont’d) Synchronized IPC(프로세스 전체를 동기화) /* signal p2 */ syncSend(message1, p2); <waiting …>; /* wait for signal from p2 */ blockReceive(msgBuff, &from); Code for p1 Code for p2 /* wait for signal from p1 */ <process message>; /* signal p1 */ syncSend(message2, p1); syncSend(…) blockReceive(…) waiting p1 p2

35 Message Protocols (Cont’d)
Message Send Using Asynchronized Transmit and Nonblock Receive Message Protocols (Cont’d) Asynchronous IPC /* signal p2 */ asyncSend(message1, p2); <other processing>; /* wait for signal from p2 */ while(!nbReceive(&msg, &from)); Code for p1 Code for p2 /* test for signal from p1 */ if(nbReceive(&msg, &from)) { <process message>; asyncSend(message2, p1); }else{ } asyncSend(…) nonblockReceive(…) p1 p2

36 Mailbox Mailbox in Process Mailbox는 일종의 Message Queue로 IPC의 하나임.
Mailbox Mechanism in Process Mailbox Mailbox in Process Mailbox는 일종의 Message Queue로 IPC의 하나임. p1’s address space는 compiler나 loader에 의해 할당됨 부주의한 Mailbox영역사용을 피해야 함 Info to be shared Info copy Address Space for p0 Address Space for p1 Message Mailbox for p1 send function receive function OS Interface send(… p1, …); receive(…);

37 Mailbox (cont’d) Mailbox in OS OS가 Mailbox를 관리하여 더 안전한 메시지 전송이 가능.
Mailbox Mechanism in OS Mailbox (cont’d) Mailbox in OS OS가 Mailbox를 관리하여 더 안전한 메시지 전송이 가능. 정보의 복사를 위해 Memory protection을 우회할 필요가 없음 공유될 정보 복사된 Address Space for p0 Address Space for p1 Message Mailbox for p1 send function receive function OS Interface send(… p1, …); receive(…);

38 UNIX Pipe Pipe란 OS가 제공하는 단 방향 통로를 이용하여 Message를 전송하는 IPC의 하나임.
Definition of Pipe UNIX Pipe Pipe란 OS가 제공하는 단 방향 통로를 이용하여 Message를 전송하는 IPC의 하나임. 방향성이 있어 한번에 한 방향으로만 데이터 전송이 가능. 공유될 정보 복사된 Address Space for p1 pipe for p1 and p2 write function read function System Call Interface write(pipe[1], …); read(pipe[0]);

39 UNIX Pipe (cont’d) 파이프 인터페이스는 파일 인터페이스와 유사함 파이프를 사용할 때 일어나는 일
Interface and Execution of Pipe UNIX Pipe (cont’d) 파이프 인터페이스는 파일 인터페이스와 유사함 open과 유사한 pipe 시스템 콜을 사용해서 파이프를 생성. File read/write 시스템 콜을 사용하여 정보를 받거나 보냄 파이프를 사용할 때 일어나는 일 파이프가 생성될 때 커널은 하나의 버퍼 생성 프로세스들은 read/write 시스템 콜을 사용해서 버퍼에서 정보를 읽어오거나 자신의 주소영역에서 버퍼로 정보를 쓸 수 있음

40 UNIX Pipe (Cont’d) Read/Write Method of Pipe
fork()시스템 콜에 의해서 생성된 자식 프로세스는 부모 프로세스와 파일 handler를 공유함 pipeID[0]은 파이프에서 읽기 위한 handler pipeID[1]은 파이프에 쓰기 위한 handler int pipeID[2]; //파이프 버퍼 . . . pipe(pipeID); //파이프 선언 if(fork() == 0) { /* the child */ read(pipeID[0], childBuf, len); <process the message>; } else { /* the parent */ write(pipeID[1], msgToChild, len); }

41 UNIX Pipe (Cont’d) Non-blocking Read write()는 비동기적인 operation임
Non-blocking Read Method of Pipe UNIX Pipe (Cont’d) Non-blocking Read write()는 비동기적인 operation임 write할 수 없을 경우 error값을 돌려줌 일반적으로 read는 blocking read read operation은 non-blocking read일 수 있음 #include <sys/ioctl.h> . . . int pipeID[2]; pipe(pipeID); ioctl(pipeID[0], FIONBIO, &on); read(pipeID[0], buffer, len); if(errno != EWOULDBLOCK) { /* no data */ } else { /* have data */