[OS] Process (2) : 프로세스

- Independent Process : 다른 Process에 의한 영향을 받지 않는다. 독립적

- Cooperating Process : 다른 Process에 영향을 받고 해당 Process가 다른 Process에 영향을 줄 수 있는 Process (가장 대표적인 예가 parent-child process)

 

[Cooperating Process의 장점]

• 정보를 공유할 수 있음
• 작업 속도 측면에서 장점을 가질 수 있음 (CPU의 분할정복 기법으로)
• 유사한 기능을 갖고 있는 것들끼리 모아서 모듈화 할 수 있음
• 편리성

 

 

Cooperating Process의 가장 대표적인 패러다임

- Producer은 정보를 만들어내는 쪽

- Consumer는 정보를 사용하는 쪽

 

ex)

Compiler가 정보를 만들어내서(Producer) buffer에 assembly code를 잠시 저장. assembler는 해당 assembly code를 사용하는 Consumer가 되는 것

 

- Buffer의 크기가 무제한일 수도 있고 제한적일 수도 있다. 하나 씩 살펴본다.

 

 

•  초기 in, out값은 모두 0
• Bounded - 크기가 제한적인 Buffer

 

 

- Producer가 생성한 정보를 어느 곳에 저장하는지 나타내는 코드 (= Insert Method)

 

 

- 생성되어있는 정보를 빼가는 counsumer 측면에서의 코드 (= Remove Method)

 

 

- 프로세스 간의 커뮤니케이션에 대한 테크닉을 IPC 매커니즘이라고 한다.

- Mechanism Process간 커뮤니케이션을 위해 사용하며 process간 동기화를 위한 매커니즘

- Shared variable를 쓰지 않고 Message Passing 기법을 많이 사용한다.

- IPC는 두 가지 기능을 제공한다.

• 고정된 크기의 fixed 또는 variable을 뒤에 붙여서 전송

- 그들 사이 커뮤니케이션을 위해서는 link가 존재해야함

- link를 구현하는 방법은 크게 physical, logical 두 가지 방식으로 나뉨

• physical : 메모리 공유, bus, 스위치, 네트워크
• logical : 직접적/간접적, 동기/비동기, 버퍼 확장 가능/불가능

 

 

• 링크를 어떻게 추구할 것인지
• 두 개 이상의 process가 연관지어 link를 생성할 것인지
• 한 쌍의 process 사이 얼마나 많은 link를 생성할 것인지
• 성능(대역폭) 관련
• 데이터를 전송할 때 불변 크기 또는 가변 크기 메세지를 보낼지
• 통신(link)는 비간접적인지 서로 직접적인지
• link가 양방향인지 단방향인지

 

• Message Passing과 Shared Memory 방식
• Message Passing은 Process A에서 시작해서 B로 보내는 것 : 커널에서 이를 지원
• Shared Memory는 여러 프로세스 간 메모리를 공유하여 그곳에 쓰기 작업하고 다른 곳에서 읽기 작업으로 공유

 

 

• 직접적으로 커뮤니케이션
• 누가 전송하고 누가 수신하는지 명확히 명시
• 커뮤니케이션 link를 고려
  • link를 자동적으로 할지
  • 한 링크 안에 오직 한 쌍만 연결시킬건지
  • 한 방향 또는 양방향으로 할지

 

• 간전적으로 커뮤니케이션
• 송신사 ↔ 수신자 사이 mailbox 또는 port가 존재 이곳들을 거쳐 전송
  • 각각의 mailbox는 unique id 존재
  • 프로세스 사이에서는 mailbox만을 이용하여 통신
• 고려해야할 사항
  • 프로세스들이 같은 mailbox를 공유해야지만 링크가 연결되도록 할건지
  • 한 링크 사이에 여러 프로세스 연결을 허락할지
  • 송신자 / 수신자 사이 mailbox 개수
  • 단뱡향 또는 양방향

 

 

• 동작과정
• 새로운 mailbox 생성
• mailbox를 통해 송신 그리고 수신 과정 진행
• mailbox 파괴

 

 

• 발생할 수 있는 문제
• mailbox를 공유하고 있기 때문에 어디로 송수신 될지 부정확할 수 있음
  • 위 문제에 대한 솔루션
  • 링크는 최대 2개의 프로세스 사이에서만 생성
  • Receive라는 명령은 오직 하나의 프로세스만 실행 가능
  • 시스템에서 랜덤적으로 하나 선택. 그리고 송신자가 누구인지 알려주는 방식

 

 

• 메세지를 주고 받을 때 주는 프로세스 / 받는 프로세스 모두 준비되어 있는 상태
• Blocking과 Non-Blocking 방식으로 나뉘는데
  • Blocking은 Synchronous방식이라 함 - 수신자가 준비 상태가 아니면 될 때까지 대기 (반대 상황도 마찬가지)
  • 송/수신 모두 준비가 되어야 링크가 형성되기 때문에 동기화방식이라 함
  • Non-Blocking은 상대 상태 고려하지 않음
  • 중간에 버퍼가 존재하기 때문에 가능함 - 버퍼에 저장 : 메세지를 수신할 수도 있고 Null을 수신할 수도 있음

 

 

• 버퍼가 있어야만 Non-Blocking / Asynchonous 방식이 가능
• 버퍼 공간이 없을 때 : Blocking 방식 또는 동기화 방식으로 해야 함 (rendezvous)
• 버퍼 공간이 있을 때 : 버퍼가 가득차기 전까지 전송 가능. 차면 기다려야함
• 버퍼 공간 제한 없을 때 : 제약 사항 없이 전송 가능

 

 

- 소켓

- Procedure Calls ; 원격으로 떨어져있는 프로그램 호출

- Method Invocation(Java) : 원격으로 떨어져있는 메소드 호출 / 객체지향 방식 (RMI방식)

 

• 통신을 위한 endpoint가 존재하고 그 사이에서 통신
• IP 주소와 Port 존재해야함
•  소켓과 소켓(한 쌍의 소켓)사이 통신

 

• 두 소켓 사이 통신을 그림으로 표현
• endpoint 1625 <-> 80 사이 통신

 

 

 

• 네트워크를 통해 원격으로 떨어져있는 프로그램을 호출
• Stubs 이용 - proxy를 통해 (안내자)
• Client-side stub은 서버가 어딨는지 알아내야하고 서버에게 전달해야할 marshall과 parameter를 모두 포장하여 전송
• Server-side stub은 메세지를 받고, unpack기능으로 모두 푼다. 그리고 실행된 결과를 다시 클라이언트쪽으로 넘겨줌

 

 

• 과정을 그림으로 표현
• 왼쪽은 Cilent / 오른쪽은 Server / 가운데는 message

1. Cilent가 요청 - 어떤 원격 프로그램을 이용하고 싶다. 어디로 연결해야하나
2. messages를 거쳐 Server로 전달 (Matchmaker - 접수처라고 생각하면 됨)
3. Server가 메세지를 받고 접속해야할 Port 정보 전달
4. Cilent가 수신한 정보를 통해 연결 시도
5. 서버 수신 및 결과 전달

 

 

• 동작 방식은 거의 유사하나 메소드 호출
• 즉 객체지향 언어에서 많이 사용 (Java)

 

 

• Cilent와 Remote Object(Server)
• 원격으로 떨어져 있는 메소드 호출을 위해 Stub를 통해 포장한 것들을 전달
• 오른쪽은 Server-side stub을 skeleton으로 표현
• stub을 수신받고 unpack한 후 메소드 실행
• 그 결과를 다시 반환