1. IPC : 프로세스들 간의 데이터 및 정보를 주고 받기 위한 메커니즘
    1. 커널에서 IPC를 위한 도구를 제공하며, System call 의 형태로 프로세스에게 제공된다.
    2. IPC에는 두가지 모델이 있다.
      1. Shared Memory 
      2. Message Passing
  2. Shared Memory : 운영체제야 단톡방 파줘!
    1. 두개 이상의 프로세스들이 주소 공간의 일부를 공유하며, Read, Wirte를 통해 통신을 수행한다.
    2. Shared Memory가 설정되면 커널의 관여없이 진행된다.
      • 장점 : 운영체제의 관여없이, 커널의 관여없이 메모리를 직접 사용하여 속도가 빠르다.
      • 단점 : 여러 프로세스가 사용하므로 구현이 어렵고 관리가 힘들다.
      • (부록) IPC를 많이한다고 context switching이 많이 일어나진 않는다.
      • (부록) 메모리 영역에 동시에 접근하기 위해서 lock이나 semaphore를 사용한다.
  3. Message Passing
    1. 커널을 경유하여 메시지를 주고 받으며, 커널에서는 데이터를 버퍼링한다.
      1. Sender
      2. Receiver
        • 장점 : 구현이 간단하다.
        • 단점 : 커널을 공유하므로 속도가 느리다.
        • (부록) 해당 프로세스 입장에서 IPC는 일종의 입출력으로 보인다. 따라서 context switching이 발생한다.
  4. Signal : 어떤 프로세스가 다른 프로세스에게 뭔가의 정보, 상황을 알려주는 것
                 (pid를 아는 특정 프로세스에게 커널을 통해 이벤트를 전달하는 방법)
    1. Synchronous signal
    2. Asynchronous signal
    3. PCB 마다 Signal handler가 있다.
      • Signal handler : 어떤 Signal을 받았을 때 특정 동작을 하도록 내가 정의하고 싶을 때, 함수를 지정해 줄 수 있다.
        sigaction이라는 함수로 구현 가능하다. 오버라이딩할 수 있다.
  5. RPC (Remote Procedure Calls) : 다른 프로세스에 있는 함수를 내 프로세스의 함수처럼 쓰고 싶어
    1. 메모리 공간에 순차적으로 쓰는 것 : Big-endian
    2. 메모리 공간에 제일 앞부분이 가장 밑에 있도록 하는 것 : Little-endian
    3. 중릭된 방식으로 쓰는 것 : External Data Representation (XDR)
  6. Pipe : 한 프로세스가 다른 프로세스로 데이터를 직접 전달하는 방법
    1. Unidirectional : 한쪽 끝에 넣으면 반대쪽으로 나온다.
    2. Bidirectional : 양쪽 끝에 넣을 수 있고 양방향으로 나온다.
    3. Half duplex : 양쪽 끝에 넣을 수 있고 반대방향 쪽으로만 나온다.
    4. Pipe는 부모, 자식 프로세스에서만 사용이 가능하다.
    5. Ordinary Pipe : 한쪽 write end에서 read end로 빠져나오는 Pipe
    6. Pipe 작동 원리 코드 ****

 

 


프로세스들이 사실 혼자 동작하지 않는다.

컴퓨터에는 여러개의 프로세스가 동작하지만 협동해서 동작하기도 한다.

여러개의 프로세스가 융합해서 동작시킨다.

 

 

어떠한 프로세스에서 처리한 경우 다른 프로세스에게 공유할 

 프로그램을 조그마하게 모듈로 만든 다음에 각각을 다른 프로세스로 만들고

다운로드 하는 애랑 그리는 애랑 따로따로 돌게 만든다.


 IPC 

프로세스들끼리 내용을 통신을 통해서 얘기하는 것이  Inter-Process Communication 이라고 한다.

IPC

 

 

 하나하나가 따로따로 프로세스가 돌고 있는 것이다.

화면에서 보여주는 브라우저 프로세스가 있다.

크롬이라는 하나의 프로그램이 사실은 여러개의 서로 다른 프로세스가 융합해서 동작한다.

 


 

 

IPC에는 두가지 모드가 있다.

 


 Shared Memory 

공유 메모리다.

프로세스들이 운영체제에게 운영체제야  다른 애들이랑 합동해서 일해야 . 판을  깔아주라”, “운영체제야,  다른 애들이랑 합동해서 일해야 하는데판에 끼워줄  있겠니?” 해서 공유하는 것이 Shared memory module 이다.

 

정리하면  프로세스들이 명시적으로 운영체제들에게 어떤 부분을 공유를 해야해서 요청을 하는 것이고 

운영체제가 해당하는 메모리를 만들어 주는 것이다.

단톡방 파줘!

 

장점 : 운영체제의 간섭을 최소화 시킬  있다.

단점 : 주어진 공간을 여러 프로세스들이 공유해서 쓰는데 누가 와서 광고지 붙이고 하니까 관리가 안된다. 공유 되어있는 데이터를 동시에 읽고 그러는  쉽지가 않다.


 Message Passing 

 Message Passing  Shared 와 반대

너네들끼리 얘기하지 말고 무조건 운영체제한테 요청해라.

그러면 운영체제는 대상 프로세스에게 패싱을 해준다. 해당하는 프로세스에게 전달을 해준다.

 

운영체제가 메시지 페싱 interface 만드는 것은 굉장히 어려운 일이다.

기본적으로 프로세스들끼리 메시지 패싱하는 동작이 Micro Kernel 핵심이다 ***

(대부분의 중요하지 않는 내용은 유저모드로 빼고 중요한 기본기능과 통신하는 모델은 운영체제의 커널로 내려가는 것이 Micro kernel 이다.)

 

Sender

Receiver

 

프로세스들끼리 데이터를 주고 받는 것이 IPC이고

IPC 모델은 두가지가 있고

두가지의 장단점이  있다.


어떤 프로세스가 다른 프로세스한테 뭔가의 정보를, 상황을 알려주는 것을 시그널이라고 한다.

시그널은 어떤 프로세스가 동작을 하다 synchronous하게 발생할  있고

우리가 잘못된 프로그램을 처리하려고 하면 운영체제가 "  이상한거 하고 있네" 하면 프로세스한테 이벤트를  알려준다. 

이게 synchronous  이벤트가 발생한 것이다.

프로세스한테 Signal 알려주는 것이다.

 

아니면 운영체제가 죽여버린다. 이게 asynchronous signal 되는 것이다.

인터럽트와 굉장히 비슷하다.

 

시그널을 받으면  프로세스마다 PCB 보면 Signal Handler라고 있다.

어떤 시그널을 받으면 어떻게 처리하시오. 이렇게  프로세스가  있다. 이게 Signal Handler이다.

기본(default) Signal Handler 있고 시그널이 맘에 안들면 오버라이딩 해서 바꿀  있다.

 

상세 설명

더보기

일종의 인터럽트라고 생각하면 된다.

Alt + F4 같은 것

프로세스끼리 서로 통신할 때 사용된다.

즉, 특정 프로세스가 다른 프로세스에게 메시지를 보낼 때 시그널을 이용한다.

 

리눅스에서 사용하는 시그널은

사용자가 인터럽트 키를 통해 발생하는 시그널,

프로세스가 발생하는 시그널,

하드웨어가 발생하는 시그널 등 매우 다양하다.

 

Signal Handler

보통 프로세스가 시그널을 받았을 때 기본 처리 방법은 프로세스를 종료하는 것이 대부분이다.

그러나 어떤 시그널을 받았을 때 특정 동작을 하도록 내가 정의하고 싶을 때, 원하는 코드를 짜서 함수를 지정해줄 수 있는데 이것을 시그널 핸들러라고 한다.

시그널을 받아서 내가 핸들할게~

대표적인 함수로 sigaction이 있다.

 

시그널 함수는 자동으로 시그널을 발생할 수도 있고 간격을 둘 수도 있고,

그냥 이벤트처럼 발생했을 때 캡처하게 할 수도 있고,

플래그를 넣을 수도 있고,

처리하기 위해 다양한 함수들이 존재한다.

 

스레드가 종료 되었을 때, 자원해제를 해주는 대표적 함수도 결국 스레드 종료를 시그널로 받아 처리하는 함수이다.

 

Signal 도 MAN 명령어가 있다.

 이렇게 Signal에 대한 모든 자세한 정보들을 확인할 수 있다.

https://jhnyang.tistory.com/143

 

[리눅스 / 유닉스 ] 시그널이란? 시그널(SIGNAL) 종류, 상황, 유사 시그널 차이점

[리눅스 유닉스 완전 정복 목차] 안녕하세요~ 오늘은 시그널 SIGNAL 에 대한 간략 포스팅을 진행하고자 합니다! 트와이스의 곡 시그널이 유행(?)하면서 시그널이 신호를 의미한다는건 다들 알고 계실거고... IT에..

jhnyang.tistory.com

 

 

 

시그널은 다양한 시그널이 있다.

각각의 의미를 알아야 다음 과제를  것이다.

 

정리 :

시그널이 해당하는 이벤트가 발생하면 운영체제가 시그널을 만들어서 던져준다.

해당하는 프로세스가 그걸 받으면 해당하는 프로세스의 시그널을 부르고

해당하는 시그널은 default값이 있고 다르면 overriding   있다. 액션을 바꿀  있다.

이것은 sigaction으로 바꿔서   있다.

 


 

시그널 핸들러 바꿔줘. Old_sa : 이전에 있던 시그널

오버라이딩 하는것.

 

Kill : 시그널을 날려버리는 

pid 프로세스에게 sig 날려줘.


 

 

 Remote Procedure Calls (RPCs) 

다른 프로세스에 있는 함수를 내가  프로세스에 있는 함수를 부르는 것처럼 사용하고 싶어.

다른 컴퓨터 네트워크에 있는 것을 쓰고 싶어 >> Remote Procedure Calls

 


 

  

 

메모리 공간에 순차적으로 쓰는  Big-endian이라고 한다.

실제 모든 컴퓨터들은 이렇게 표현하지 않는다.

 

실제로는 메모리는 뒤집어서 써놓는다. OD OC OB OA

숫자를 뒤집어서 배열의 제일 앞부분을 제일 마지막 자리수가 차지하게끔 한다.

이렇게 쓰는 것을 Little-endian이라고 한다.

 

그래서 컴퓨터마다 쓰는 방법이 다를  있다.

그러면 collaborate  수가 없게 된다.


 

그래서 중립되어 있는 방식으로 표현하자 >> External Data Representation(XDR)

 


Pipe

Inter Procedure 메커니즘 중에 옛날부터 써왔던 IPC 메커니즘 >> Pipe

파이프 끝에다가 물을 넣으면 반대쪽으로 나온다. >> unidirectional

양쪽으로 양방향 통신이 되느냐 >> bidirectional

Bidirectional  왼쪽에서 넣으면 오른쪽에서만 나오는 (반대 방향도) >> half duplex

 

상세 설명

더보기

 파이프의 느낌은 슈퍼마리오의 게임에서 파이프를 타고 입구와 출구를 오가는 그런 느낌이다.

IPC에서 Pipe를 간단하게 설명한다면,

여러개의 프로세스가 공통으로 사용하는 임시공간 이라고 할 수 있다.

 

그리고 그 임시 공간은 실제로 파일 시스템에 생성되는 임시 파일이다.

하나의 프로세스가 파이프에 쓰게 되면 다른 프로세스는 그 파이프에서 읽는 방식으로 쓰게 된다.

 

파이프는 시스템 내부에서 관리하는 임시 파일을 이용하므로,

다른 IPC 기법 중 하나인 Signal 과는 다르게 대용량의 메시지도 전송이 가능하다.

 

이런 파이프는 보통 익명의 파이프와 이름을 가진 Named Pipe의 두가지 방법으로 사용할 수 있도록 OS가 제공한다.

 

파이프는 소켓 등의 비하면 꽤 단순한 IPC 기법으로 여러가지 특징을 가지고 있습니다.

 

그중 첫번째 특성은, 파이프는 입구와 출구의 개념이 없다는 것입니다.

파이프는 단순한 통로 입니다. 

방향성이 없기 때문에 자신이 쓴 메시지를 자신이 읽을 수 있다는 것을 항상 유의해야 합니다.

 

그렇기 때문에 두개의 프로세스가 통신할 때는 

읽기전용 파이프와 쓰기전용 파이프의 두 개의 파이프를 쓰게 됩니다.

두개의 파이프를 생성하고, 한쪽 파이프를 일부러 닫아 버리는 것이지요.

 

또 파이프의 특성 중 유의할 것은 파이프는 fork() 함수에 의해 복사 되지 않는다는 것입니다.

 

fork() 함수에 의해서 프로세스가 생성되면, 자식 프로세스는 부모가 사용하던 변수를 복사하게 됩니다.

하지만 파이프의 경우 복사되는것이 아니라 File Descriptor 를 공유하게 됩니다.

 

즉 자식 프로세스와 부모 프로세스가 같은 파이프를 가리키게 됩니다.

 

그외에도 익명의 파이프는 또 하나의 주요한 특성이 있습니다.

부모 자식프로세스 사이에서만 Pipe가 사용 가능하다는 것입니다.

 

파이프는 운영체제에서 임시로 생성되는 파일이고, 접근 가능한 방법은

File Descriptor(파일 디스크립터) 를 공유하는 방법만이 존재합니다.

 

익명의 파이프는 부모와 자식 프로세스만이 파일 디스크립터를 공유하므로

다른 프로세스는 파이프를 사용하여 통신이 불가능 합니다.


 

 Ordinary pipe  >>  쪽이 write end 에서 read end  빠져나오는 파이프

Parent-child 관계에서만 쓰인다. 


 

 


File descriptor라는  쓴다.

 : 입력과 출력을 abstract하는 

 

0 1 인덱스를 가진 file descriptor라는  >> int pipefd[2];

pipe(pipefd) >> pipe라는 시스템 콜로 명령어로 fd 넘겨주면 이것을 파이프로 만들어 준다.

 

 

이것을 fork  엮는다.

pipe 만들고 fork 하면

parent  쓴게 child로도 만들어진다.

child에서  것을 parent에서도 읽을  있다.

이렇게 파이프가 구성된다.

 

만약 child에서   parent에서 읽지 않게 닫아주려면

close(pipefd[0])으로 닫아버리면 된다.

 

child에서 쓰는 파이프를 닫아버리면 0 파이프에서 읽어만 가면 된다 하면은

 

  파워풀  

다루진 않겠다.

 

정리 :

컴퓨터에는 프로세스가 여러개가 있다. 서로 공유한다.

IPC라고 하고 두가지 방법이 있다. 

Shared  message passing

장단점이 있다.

어떤 프로세스가 다른 프로세스에게 이벤트를 날려주는 것을 Signal이라고 한다.

어떤 프로세스가 다른 컴퓨터에 있는 것을 함수 부르듯 갖다 쓰는 것을 Remote procedure call 이라고 하고

  얘기 한게 Data represent 다르기 때문에 그걸 표현하는 External Data Represent 방법이 필요하다. (XDR)

한쪽에서 밀어내면 다른 쪽에서 꺼내가는 파이프에 대해서 얘기했고

Ordinary 파이프가 있다.

 

 

 

'🚦 Server > Operating System' 카테고리의 다른 글

08. Threads (2)  (0) 2020.04.23
07. Threads (1)  (0) 2020.04.21
05. Processes  (0) 2020.04.06
04. Operating System Structures (2)  (0) 2020.03.30
03. Operating System Structures (1)  (0) 2020.03.25
복사했습니다!