비-블로킹 I/O 동작은 

태스크가 시스템콜을 호출했으나

점유하고자 하는 데이터를 즉시 가용하지 않을 경우 

즉각 리턴을 하는 것을 특징으로 합니다.

 

 

 


non-blocking IO는 뭘까요?

 

kbheat 함수는 getch 함수와 기능적으로 다른 점이 두 가지가 있습니다.

첫째, kbheat 함수는 getch 함수와 달리

키가 눌렸는지 안 눌렸는지만 확인해주는 함수입니다. 

즉, 키가 눌렸어도 어떤 키가 눌렸는지 까지는 알 수 없습니다.


둘째, kbheat 함수는 getch 함수와 달리 

non-blocking I/O 함수입니다. 

키의 상태를 가지고 즉각 리턴하는 특징을 가지고 있죠.

 

 


위와 같은 특징 때문에 

논블로킹 방식으로 키를 처리하고 싶다면

먼저 kbheat 함수를 이용해 키의 상태를 확인 후

키가 눌렸다고 판단되면 getch 함수를 다시 호출 해주어야 합니다.

 

논블럭이라고 하는 것은 무엇일까요?
이 함수 kbheat를 호출해도 

애플리케이션이나 태스크가 휴면 상태로 들어가지 않는 겁니다.

 



프로세스가 휴면 상태로 가지는 않고 

사용자가 키를 안 눌렀을 경우는 

그냥 함수 리턴을 하게 되는 겁니다.

 

이 방법을 사용할 경우, 그림처럼

kbheat 함수의 지속적인 호출이 필요합니다.


왜냐하면 non-blocking 방식이기 때문에 

태스크가 휴면 상태로 가지는 않거든요.



kbheat 함수의 호출은 즉각적인 반응을 보이게 돼서 

키가 눌렸니? 안 눌렸는데.

키가 눌렸니? 아니 안 눌렸어.

키가 눌렸니? 눌렸어.

 

이런 식으로 처리됩니다.

 


이런 처리 방식 때문에 

논블럭 모드에서는 태스크는 휴면하지 않습니다.


애플리케이션이 휴면하지 않고 

부정적인 답변을 계속 받다가 

언젠가는 긍정적인 답변, 즉 키가 눌렸음을 받죠. 

 

이 방식의 장단점을 이해해 봅시다.

다음 예시를 보시겠습니다.

non-blocking 함수 예시


여기서 main 함수는 휴면 가능한 함수입니다.
getch 함수 자체는 블록킹 함수입니다.
하지만 main 함수는 논블록킹 함수입니다.

 

kbheat는 어떤 키가 늘렸는지는 알려주지 않습니다.

키가 눌렸다, 안눌렸다만 알려줍니다.
어떤 키가 늘었는지는 결국 이 getch 함수를 불러야만 알 수 있습니다.

 

그러면 이것을 왜 이런 방법으로 구현했을까요?
non-blocking 만의 장점을 가지고 있기 때문이죠.


이것이 무슨 장점이 있는지 이해하시려면 

블록킹 방식의 코드가 어떤 불편한 점이 있는지를
먼저 이해하셔야 합니다.

 


이 함수는 어떻게 되나요?

Blocking I/O 함수의 예


이 함수는 블록됩니다.
이 함수로 인해 태스크는 휴면 상태로 가게 됩니다.


getch 함수를 실행해 버리면 

여기 밑에 부분에 있는 코드가 실행이 안됩니다.

루프 모드로 되어 있지만

루프는 태스크가 휴면에서 깨어나기 전까지는

실행이 안될 겁니다.

이게 블록킹의 장점이자 단점이죠.

 

장점은 뭘까요?
태스크가 이벤트를 기다릴 때 휴면하면서 기다릴 수 있다고 하는 것은 장점이에요.
CPU 시간을 사용하지 않으면서 기다릴 수 있기 때문에 장점이에요.

 

단점은 휴면 상태 있는 동안 아무 코드도 실행할 수 없어요.
이게 단점인 것입니다.

 

하지만 블록킹 모드가 아닌 논블록킹 모드에서는 

CPU 시간은 계속 사용하고 있죠.

휴면하지 않고 루프를 회전시킬 수가 있어요.


그래서 사용자가 키보드를 눌렀을 때 

이 안으로 진입해서 처리할 수 있게끔 하는 거죠.



이처럼 논블럭킹과 블럭킹의 차이를 이해하는 것은 

RTOS 프로그래밍에서는 필수적입니다.

'[2025~] Embedded > Free RTOS' 카테고리의 다른 글

[Free RTOS_017] RTOS란?  (0) 2025.03.07
[Free RTOS_016] 커널의 시계  (0) 2025.03.07
[Free RTOS_014] 블로킹 IO  (0) 2025.03.07
[Free RTOS_013] 인터럽트  (0) 2025.03.07
[Free RTOS_012] 우선순위 스케쥴링  (0) 2025.03.07

+ Recent posts