Process
- 프로세스들을 Scheduling queues라는 곳에 보관하는데 queue의 종류는 크게 3가지로 나눌 수 있다.
1. Ready queue : 메인 메모리에 존재하지만 아직 실행 단계는 아닌 애들을 담아두는 곳이다.
2. Wait queue : 외부에 이벤트를 기다리는 프로세스들이 존재하는 곳이다.
3. Device queue : 디바이스마다 가지고 있는 queue로 특정 디바이스들의 이벤트를 기다리는 곳이다.
만약 프로세스1이 동작을 하다가 프로세스2가 동작하기 위해 cpu를 넘겨줘야 하는 상황이라면,
운영체제는 프로세스 1의 PCB 정보를 메모리에 저장하고 프로세스 2의 PCB정보를 CPU에게 넘겨서 다시 실행하게 된다.
프로세스는 또 다른 프로세스를 만들기도 한다. 즉 부모 프로세스와 자식 프로세스가 생기는 것이다.
이 둘은 서로 같은 자원을 공유한다. 부모 프로세스는 자식 프로세스에 관한 모든 권한을 다 접근할 수 있지만 자식 프로세스는 일부만 접근 가능하다.
또한 자식 프로세스는 부모 프로세스의 PCB를 그대로 복사한 뒤에 할당된 동작을 덮어 씌운다. 하지만 모두 다 똑같은 것은 아니다. PID와 같은 고유한 것들은 다르다. 그리고 모든 부모 프로세스는 자식 프로세스가 종료되기까지 기다린다. (물론 예외는 있다)
예를 들어 UNIX에선 fork()라는 시스템 콜을 이용해 새로운 자식 프로세스를 생성하고, exec()를 이용하여 새로 생성된 프로세스를 메모리 상에 올리고, wait()을 이용해서 자식 프로세스가 끝날 때까지 기다려준다.
Interprocess Communication (IPC)
- 이제 프로세스들이 어떻게 서로 정보를 주고 받는지 알아보자. 프로세스 사이에 소통하는 2가지 방식이 있다.
1. Shared memory
- user에 의해서 만들어지는 것으로, 만약 두 개의 통신을 할 때 공통된 메모리를 통해 주고받는다.
데이터가 이동하는 속도( =메모리 접근 속도 )가 빠르고 구현하기 쉽다는 장점이 있다. 하지만 운영체제가 없으니 부가적인 동작이 필요한데 가령 동기화 같은 문제가 발생한다.
어떻게 구현할 수 있을까? 2가지 방법이 있다.
1. Unbounded- buffer
- 공유되는 데이터의 사이즈( 용량 )에 제한이 없다. 그러니 전송하는 입장에서는 전송만 하면 되니 계속 데이터를 보내게 된다. 하지만 데이터를 받는 프로세스는 버퍼가 채워질 때까지 기다려야 하는 문제가 있다.
2. bounded- buffer
- 공유되는 데이터의 사이즈 (용량 )에 제한이 있다. 전송하고자 했을 때 만약 버퍼가 가득 차 있다면 데이터의 전달 자체를 못한다는 단점이 있다. 다시 말해, 버퍼의 자리를 기다려야 한다.
만약 10개의 버퍼를 사용한다고 하여 생성했다면 우린 9개의 버퍼만 사용할 수 있는데 이유는 이 버퍼의 상태를 나타내기 위해 1개를 사용해야 하기 때문이다.
하지만 N개를 모두 다 사용하기 위해 counter라는 새로운 변수를 추가하는 방법이 있다. 데이터를 보내는 쪽에선 counter를 1씩 증가시키고 받는 쪽에선 가져가고 counter를 1씩 감소시킨다.
근데 이게 문제다 cpu의 동작이 섞이면 어떻게 될까?? counter의 업데이트 값이 달라지는 문제가 생긴다. 이런 걸 Race Condition라고 부른다. 마치 Arm 프로세서에서 SWP명령어의 문제와 똑같다. 해결방법에 대해선 찾아보지 않아서 모르겠지만 뭔가.. 동작의 구분을 하여 수행할 거 같다.
2. Message passing
- 운영체제를 통해 만들어지는 것인데 kernel을 통해 통신하는 것이다. 모든 데이터의 전송과 송신을 운영체제가 맡아서 해준다는 말인데 시스템 콜을 이용하여 주고받으니 적은 양의 데이터를 주고받을 때 적합하다.
당연히 양이 많아지면 시스템 콜도 많이 해야 하니 전체적으로 overhead가 증가하는 결과가 나온다. 하지만 운영체제가 맡아서 해주니 부가적인 동작이 필요 없다.
communication link를 생성하여 send, receive operation을 동작한다. 그렇다면 어떻게 link를 생성할까?
가장 심플하게 보면 직접적으로 보내는 방법이 있다 (direct)
다른 방법은 mailbox라는 포트를 생성하여 여러 프로세서가 동일한 mailbox를 통해 서로 주고받는 방법이 있다.(indirect)
이 방법은 여러 개의 프로세스가 동일한 mailbox를 사용하니 2개 이상의 프로세스가 동시에 receive를 호출했을 때의 문제가 있다.
해결 방법으로는
1. 프로세스의 쌍을 맞추거나
2. 특정 프로세스에게 시간적 제한을 두고 receive를 하게 하거나,
3. 정보를 전달한 프로세스에게 어떤 프로세스가 가져갔는지 알려주는 방법이 있다.
동기화
- 이렇게 프로세서들 사이의 통신에서 가장 큰 이슈는 동기화의 문제다. 동기화는 Blocking이고 비동기화는 Non-Blocking이다.
Blocking send는 보내고 받을 때까지 기다리는 것이다.
Blocking receive는 메시지가 도착할 때까지 멈춰있는 것이다. 이건 전달자와 수신자가 모두 같은 상태에 있기 때문에 동기화 상태이다.
Non-Blocking send는 수신자가 받건 말건 하던 일을 계속한다.
Non-Blocking reciver는 메시지가 있으면 받고 없으면 넘어가는 방법이다.
댓글