[OS] 공룡책 Chapter3 정리 프로세스, PCB, 스케쥴링 큐, context switch, IPC, RPC, PIPE

틀린 내용 있으면 꼭 댓글 달아주세요. 

프로세스

프로세스는 실행 중인 프로그램

프로그램은 passive entity(디스크에 저장된 file)

프로세스는 acitive entity(프로그램이 메모리에 올려진 상태에서 실행되는 것)

process state

프로세스는 실행시 상태가 바뀌며 아래의 상태로 정의할 수 있다.

• new : 프로세스가 생성된 것
• Running : 명령어들이 실행중인 것
• Waiting : I/O와 같은 이벤트로 인해 대기중인 것
• Ready : 프로세서(프로세스를 실행시키는 유닛)에게 할당되기를 기다리는 것
• Terminated : 프로세스 실행이 끝난 것

PCB

PCB는 아래의 정보를 갖고 있다. 프로세스를 운영체제 위에서 표현(보여주기 위한) 정보들을 담고 있다. (프로세스별로 바뀌는 정보에 대해 갖고 있음)

• process state : 프로세스의 상태(new, running, waiting, ready, terminated)
• program counter : 프로세스가 다음에 실행할 명령어 주소를 가리킴
• cpu registers
• cpu-scheduling information : 프로세스 우선순위, 우선순위 큐에 대한 포인터, 다른 스케쥴링에 대한 파라미터에 대한 정보를 갖고 있음
• memory-management information : 레지스터의 limit와 base에 대한 정보, 페이지 테이블, 세그먼트 테이블
• Accounting information : cpu 사용량, 시간 제한, account number, job이나 process number같은 정보
• I/O status information : 프로세스에 할당된 I/O 디바이스 정보와 프로세스로 열은 파일 리스트

Scheduling Queue

1. 프로세스가 시스템에 들어오면 ready queue에 연결리스트 형태로 올라감
2. 프로세스는 실행되기 위해 할당될 때까지 기다림
3. 프로세스가 CPU core에 할당되면 아래 중에 하나가 발생함
   • 프로세스가 I/O를 요청하여 I/O 대기 큐에 넣음
   • 프로세스가 자식 프로세스를 만들고 본인은 대기 큐에서 그 자식프로세스가 종료될 때 까지 기다림
   • 프로세스가 인터럽트나 할당 시간이 만료되어 cpu 코어로부터 강제적으로 remove되면 준비 큐에 다시 들어감
   처음 두 경우는 대기->준비 상태로 바뀌고 ready queue에 넣음. 프로세스는 이 과정을 종료될 때 까지 반복하며 종료되면 모든 큐에서 삭제되고 해당 프로세스의 PCB와 자원 할당을 해제함

Context Switch

프로세스가 인터럽트나 시스템 콜에 의해서 실행중인 프로세스를 잠깐 냅두고 다른 프로세스를 처리하고 오는 것

1. 프로세스 p1이 프로세스 p2에 의해 인터럽트 당함
2. 운영체제는 p1에 대한 정보를 PCB1에 저장
3. 그리고 PCB2에서 p2의 정보를 reload함
4. p2를 실행
5. p2가 끝나거나 p1에 의해 인터럽트/시스템 콜로 호출당하면 p2에 대한 정보를 PCB2에 저장
6. PCB1에서 p1에 대한 정보 reload
7. p1 실행

context switching 하는 비용 (저장하고 리로드)도 있어서 너무 자주하면 프로세스가 처리하는 일보다 context switching하는 비용이 큼

메모리 관리 기법에 따라 좌우됌

interprocess Communication(IPC) 중요

IPC에는 2가지 기법이 있다.

• 공유 메모리(프로세스간 같은 메모리 사용)
  • 일반적으로 한 프로세스가 다른 프로세스의 메모리 영역에 접근하는 것을 금지함
  • 공유 메모리 세그먼트에 데이터를 넣고 읽는 방식
• message passing(커널의 개입)
  • 프로세스 P1이 프로세스 P2에게 전달하기 위해서
  • P1이 커널에 메시지를 보냄
  • 커널이 P2에게 전달
  • 프로세스들에 의해 교환되는 메시지는 임시 큐에 있다. 아래는 구현 방법
    • zero capacity : 큐의 최대 길이가 0. 송신자는 수신자가 메시지를 수신할 때 까지 기다려야 함
    • bounded capacity : 길이가 n. 송신자는 큐 안에 공간이 없으면 blocking됨
    • unbounded capacity : 길이가 무한. 송신자는 non blocking

PIPE

두 프로세스가 통신할 수 있게 하는 IPC 기법 중 하나.

사용하기 위해서는 4가지를 고려해야함

1. 파이프가 양방향이나 단방향 통신을 허용하는가?
2. 양방향과 단방향을 허용한다면, half duplex(반이중: 한번 전송할 때 한 방향으로 전송)인가 full duplex(전이중: 한번 전송할 때 쌍방에서 전송)인가?
3. 통신하는 프로세스간 부모-자식과 같은 관계가 존재해야만 하는가?
4. 파이프가 네트워크를 통해 통신할 수 있는가? 아니면 같은 머신 안에서만 통신 가능한가?

Ordinary pipe

두 프로세스간 생산자-소비자 형태로 통신함

A프로시저는 write만 하고 B프로시저는 read만 처리. 따라서 단방향 통신

양방향 통신하고 싶으면 파이프를 2개 준비해야함.

파이프는 파이프를 생성한 프로세스 외에는 접근 불가능. 따라서 부모 프로세스가 파이프를 생성하고 fork()로 자식프로세스와 통신하기 위해 사용함.(자식 프로세스는 부모 프로세스의 메모리를 copy된 상태로 생성되는 것을 잊지 말자)

Named pipe

ordianry pipe는 두 프로세스가 서로 통신하는 동안에만 존재. 통신을 끝내고 종료하면 없어짐.

named pipe는 양방향 통신 가능하며 부모-자식 관계 필요없음.

통신 프로세스가 종료되어도 named pipe는 계속 존재함

파이프 예시

한 명령어의 출력이 두 번째 명령어의 입력으로 사용되는 경우, unix 명령어 라인의 환경에서 매우 자주 사용 됌.

ls로 긴 목록을 출력하고 more가 한 화면마다 스페이스로 넘기면

ls와 more 사이에 파이프를 연결하고 ls가 한 화면을 생성하고 more가 생성된 화면을 소비하는 생산자-소비자 패턴을 갖게 된다.

RPC(remote Procedure Call) 중요

RPC는 네트워크에 연결되어 있는 두 시스템 사이의 통신에 사용하기 위해 프로시저 호출을 추상화하기 위해 설계되었다. (분산 네트워크 컴퓨터 환경에서 프로그래밍을 쉽게 하기 위해)

RPC의 궁극적인 목표

• 클라이언트-서버간 커뮤니케이션에 필요한 정보는 최대한 숨기고
• 클라이언트는 일반 함수를 호출하는 것 처럼 호출
• 서버도 마찬가지로 함수 호출하듯이
• 궁극적으로 원격 프로시저를 함수 호출하듯이 편하게 호출하는게 목표

IPC 메시지와 대조적으로 RPC는 구조화 되어 있어서 단순한 패킷 데이터가 아니다.

각 메시지는 원격 포트에서 listening중인 RPC 데몬의 주소가 지정되어 있고 각각의 실행될 함수랑 전달될 매개변수를 구분하는 id를 가진다.

요청된 함수가 실행되고 어떤 출력이든 별도의 메시지를 통해 요청자에게 반환된다.

RPC는 클라이언트가 자기 로컬에서 프로시저 호출하는 것 마냥 원격의 프로시저를 호출할 수 있게 해줌. RPC 시스템은 클라이언트 쪽에 stub을 제공하여 통신하는데 필요한 자세한 것들을 숨겨줌으로써 추상화함.

parameter marshalling : 프로시저에게 갈 매개변수를 네트워크로 전송하기 위해 적절한 형태로 재구성해주는 작업

XDR(external data representation) : 컴퓨터 구조마다 데이터를 처리하는 방식이 다를 수 있음. (최상위 비트를 먼저 읽거나, 최하위 비트를 먼저 읽거나. e.g: little endian, big endian)

따라서 이를 통일해서 표현하기 위한 방식이 XDR.

보내기전 XDR에 맞춰서 가공해서 보내주고 받는 쪽에선 XDR을 풀어서 받아들임

 

반응형

RPC에서 중요한 문제 2가지

1. at most once(정확히 한번은 서버가 받기 위한 것)
   • 네트워크 오류 때문에 실패하게 되면 메시지가 중복되어 여러번 호출 될 수 있다.
     • 각 메시지에 타임스탬프를 기록하는 방식으로 중복을 체크할 수 있다.
2. exaclty once : 클라이언트에게 서버가 요청을 잘 받았음을 ACK로 전달하는 것  
   
   1. at most one + 클라이언트 식별
   2. 클라이언트가 서버로부터 요청을 제대로 받았음을 ACK로 확인하기 위함
3. 클라이언트-서버간 통신 문제
   • 프로시저 호출은 binding 작업이 link/load/execution 시점에 행해짐
   • 이 때 프로시저의 이름이 프로시저의 메모리 주소로 변환 됨
   • RPC도 클라이언트와 서버 포트를 바인딩해야함. 공유 메모리가 없어서 알 방법이 없음. 여기에는 2가지 방법이 있음
     1. 고정된 포트 주소 형태로 미리 정하기
        • 컴파일때 RPC에게 포트 번호를 고정시켜서 바뀌지 못하게 함.
     2. 랑데부 방식에 의해 동적 바인딩
        • OS는 미리 정해져 있는 고정 RPC 포트를 통해 랑데부용 데몬을 제공함
        • 클라이언트는 자신이 실행하기 원하는 RPC 이름을 담고 있는 메시지를 matchmaker에게 보내서 RPC 이름에 대응하는 포트 번호를 알려달라고 요청
        • 포트 번호가 클라이언트에게 반환
        • 시스템이 crash되거나 프로세스가 종료되지 않는 한, 클라이언트는 요청을 RPC 포트번호로 보냄
        • 초기에 셋팅하는 오버해드가 있지만 동적인 방식이라 유연함.
          • 랑데부용 데몬을 matchmaker라고 부른다.
          • 데몬: 백그라운드 프로세스

장점

• 쉽게 사용할 수 있고 프로그래밍 부담이 적음
• 시스템에 정의된 RPC 함수들이 많지 않아서 응용하는데 한계가 있음

 

 

 

참고) procedure(프로시져)는 실행할 명령 정도로 이해하면 된다. 함수와의 차이는 함수는 값을 리턴하고 프로시저는 실행하고 끝인 것.  한국어로는 절차 호출이라고 불린다.

레퍼런스

https://nesoy.github.io/articles/2019-07/RPC