[OS] Busy Waiting 정의

Busy Waiting 이란 무엇일까?

바쁜대기라고 불리움.
• OS에서는 원하는 자원을 얻기 위해 기다리는 것이 아니라 권한을 얻을 때까지 확인하는 것을 의미한다.
• CPU의 자원을 쓸데 없이 낭비하기 때문에 좋지 않은 쓰레드 동기화 방식이다.

쓰레드의 동기화를 위해서 Busy Waiting Method를 사용할 것이 아닌, 뮤텍스 세마포어(Mutual Exclusion) 또는 Monitor를 사용해야 한다고 알려져 있다.

뮤텍스 세마포어(Mutual Exclusion) 또는 Monitor 방법의 경우 CPU가 계속해서 쓸데없이 무한 루프를 돌면서 확인하는게 아닌, 어떤 쓰레드가 공유 자원을 획득한 경우 다른 쓰레드는 그 쓰레드는 공유 자원을 모두 사용할 때 까지 기다린다.

또한, 쓰레드가 공유자원을 모두 사용하면 그때 기다리고 있던 다른 쓰레드를 깨우는 방식이다.

이렇게 하게 된다면, 쓸데 없이 기다리는 쓰레드 공유 자원에 접근할 수 있는지 지속해서 확인할 필요 없이, 기다리다고 알아서 깨워주기 때문에 훨씬 자원 낭비가 덜하다.

Monitor를 사용하게 된다면 뮤텍스락(할당, 해제)의 관리를 알아서 해주기 때문에 조금더 간단하지만, 시스템 별로 뮤텍스락만 지원하는 경우가 있고, Monitor를 지원하는 경우가 있기 때문에, Monitor가 사용 가능 하다면 웬만하면 Monitor를 사용하는게 효율적일 것이다.

뮤텍스 세마포어(Mutual Exclusion)를 사용하는 경우 Monitor를 사용하는 것과 동일한 효과를 낼수 있다. 하지만 사용자가 직접 락을 얻고 해제하는 코드를 작성해야 하며, 실수로 크리티컬 섹션을 뮤텍스 락으로 감싸는 것을 깜빡할 수 있는 실수의 여지도 생기기 때문에 웬만하면 Monitor를 사용하는것을 추천한다.

Monitor 는 뮤텍스 락으로 감싸져있다. 그리고 뮤텍스락을 얻은 뒤에 공유 자원에 접근하고, 전체를 사용한 다음엔 뮤텍스 락을 해제 한다. 뮤텍스 세마포어도 같은 방식이다.

사용할 수 있는 공유 자원의 개수가 1개가 아니라 여러개일 경우 카운팅 세마포어를 사용한다.

공유 자원이 6개가 있는 동안 12개의 쓰레드가 동시에 돌고 있을때 한번에 6개의 쓰레드가 공유 자원에 접근해도 문제가 발생하지 않을 것이다. 하지만 그 이상 접근하면 Race Condition이 발생한다.

그렇기 때문에 공유 자원의 개수를 카운팅 하면서 락을 걸어야 한다. 즉, 현재 사용 할 수 있는 자원이 몇개인지를 카운트하는데, 0개인 상태에서 다른 쓰레드가 또 그 공유 자원에 접근하려고 하는 경우 그 쓰레드 부터는 막아야 한다.

그리고 나서, 현재 공유 자원을 쓰고 있던 쓰레드중 하나가 사용을 다 한 다음에 뮤텍스 락을 반납한 경우 그 기다리고 있던 쓰레드 중 하나를 깨워서 크리티컬 섹션에 입장 시킨다.

이런 방식으로 쓰레드를 동기화 하는 방법이 카운팅 세마포어이다.

결국엔, 그냥 뮤텍스 세마포어 인데 공유 자원이 여러개인것만 다른것이다.

 

그럼 Busy Waiting은 언제 사용하는게 효율적일까?

• 자원의 권한을 얻는데 많은 시간이 소요되지 않는 상황인 경우에 사용하는 것이 효율적이다.
• Context Switching 비용보다 성능적으로 더 우수한 상황인 경우에 사용하는 것이 효율적이다.

Busy Waiting의 단점은?

• 권한 획득을 위해 많은 CPU를 낭비한다.

Busy Waiting 말고 다른 방법은?

• Busy Waiting말고 Sleeping이라는 방법이 있다.

Sleeping 이란?

• 권한을 얻기 위해 기다리는 시간을 Wait Queue 에 실행 중인 Thread 정보를 담고 다른 Thread에게 CPU를 양보하는 것을 의미한다.
• 커널은 권한 이벤트가 발생하면 Wait Queue 에 담긴 Thread 정보를 깨워 CPU에 부여한다.

Sleeping은 어떤 상황에서 쓸까?

• 기다리는 시간이 예측 불가능한 상황에서 쓰인다.

Sleeping의 단점은?

• Wait Queue에 넣는 자원 비용 + Context Switching 비용

Reference )

https://simsimjae.tistory.com/289

https://nesoy.github.io/articles/2019-06/OS-Busy-Waiting