blocking 과 non blocking

비동기 이벤트 기반 방식을 다루기 전에 그 이외의 방식을 다뤄보자

 

1. blocking vs non blocking

blocking 과 no blocking은 호출되는 함수가 바로 리턴이되는가의 여부가 관심사이다. 

blocking의 경우 바로 리턴되지 않으며, non blocking의 경우에는 바로 리턴이 된다.

 

2. sync vs async

이 두가지는 상호 비교 대상이 되기 어려운데 바라보는 관점이 다르기 때문이다.

sync/ async 는 호출되는 함수의 작업 완료 여부를 누가 신경쓰냐가 관심사이다. 

sync (동기 기반) : 

호출되는 함수의 작업 완료 여부를 신경쓰는 것은 호출하는 함수이다.

즉 작업을 요청한 측에서 작업의 완료여부를 체크한다.

async (비동기 기반) :

호출되는 함수의 작업 완료여부를 신경쓰는 것은 호출되는 함수이다. 

즉 작업을 요청 받은 측에서 작업의 완료 여부를 알려준다.

• blocking의 경우 (sync blocking)

blocking I/O 에서는 하나의 프로세스가 어떤 자원을 사용할때, 그 자원을 다른 프로세스가 점유하고 있다면, 그 프로세스가 그 자원의 내용을 끝마칠 때까지 기다려야 한다. 

 

blocking I/O 환경에서는 IO를 수행하기 위해선 커널에 한번 이상 시스템 콜을 보내야 된다.

시스템 콜을 보내면 그 순간 커널로 제어권이 넘어가고 이 과정이 context-switch이다. 

제어권이 커널에서 유저의 프로세스(혹은 스레드) 로 돌아오기 전까지 시스템 콜은 block이 된다.

그림과 같이 애플리케이션에서 read() 함수를 호출하면 운영체제에게 (운영체제의 커널에) 시스템 콜이 날아간다.

커널은 파일을 읽기 위한 동작을 수행하고 파일을 다 읽어야지 반환 신호를 보내며, 반환이 되기 전까지는 다른 애플리케이션은 read()를 호출할 수 없다. 

 

• async blocking 의 경우

이 모델에서는 IO 는 non blocking 이지만, 통지는 blocking 방식이다.

select()는 유저 프로세스를 block 한다. 

select() 는 데이터가 사용이 가능해지면 통지를 받게 되는데, 그때 block을 푼다.

다음과 같은 그림을 보면 더 이해가 되지 않을까

 

• non blocking의 경우( sync non-blocking)

 

 

시스템 콜이 들어오면, 커널을 IO 작업의 완료 여부와는 무관하게 즉시 응답을 해준다. 

만약 완료가 되지 않았다면 에러코드를 응답한다. 

그래도 이는 커널이 시스템 콜을 받자마자 제어권을 다시 유저 프로세스에게 넘겨준다는 것이다.

때문에 유저 프로세스는 IO가 완료되기 전에 다른 작업을 할 수 있다. 

유저 프로세스는 다른 작업들을 수행하다가 중간 중간 시스템 콜을 커널에게 보내 IO의 완료 여부를 물어본다.

 

 

• async non-blocking 의 경우

시스템 콜이 들어오면 커널은 IO 작업 완료 여부와는 무관하게 즉시 응답을 해준다.

유저 프로세스는 IO의 완료 되기 전에도 다른 작업을 할 수 있다.

IO처리는 백그라운드에서 실행되어지며, 완료되면 커널이 유저 프로세스에게 알려준다.

sync non blocking은 IO 의 완료여부를 계속 커널에게 물어봐야되었지만, 

aysnc non-blocking은 IO완료가 되면 커널이 유저프로세스에게 알려주는 방식이다.

 

 

참고자료

ibm 아티클

https://limdongjin.github.io/concepts/blocking-non-blocking-io.html#ibm-%E1%84%8B%E1%85%A1%E1%84%90%E1%85%B5%E1%84%8F%E1%85%B3%E1%86%AF

쉽게 정리한 네트워크  https://niklasjang.tistory.com/57?category=923998