Description
현재 Semaphores의 단점으로 busy waiting이 제시되었는데, 일반적인 Semaphores은 critical section에 진입 시도했지만 실패한 프로세스를 block시키기 때문에 busy waiting 문제는 생기지 않습니다.
대신 block시키고, 다시 불러오는 과정에서 overhead가 큰 경우에 차라리 그냥 block시키지 않고 그대로 진입 코드를 매번 실행시키도록 하는 spinning lock이 사용될 수 있고, 이 때 매번 진입 코드를 실행시키는 것을 busy waiting이라고 말합니다. 본문에서 말씀해주신대로 순수하게 낭비하는 시간이기 때문에 deprecated되었지만 critical section이 매우 자주 발생하거나, 짧은 경우, busy waiting이 blocking보다 높은 성능을 보장할 수 있기 때문에 상황에 따라 채택할 수 있는 방법입니다.
본문의 기존 설명에는 semaphores가 기본적으로 busy waiting을 하는 것을 가정하고 있지만, busy waiting을 하는 semaphores는 spin lock으로 불리며 특수한 case입니다(초기 버전). 현재 쓰이는 semaphore은 기본적으로 blocking하는 것이 일반적이므로 본문의 단점 사례를 바꿔서 오해를 방지하는 것이 좋을 것 같습니다.
대안 제시
단점
Busy Waiting(바쁜 대기)
Critical Section 에 진입해야하는 프로세스는 진입 코드를 계속 반복 실행해야 하며, CPU 시간을 낭비하게 된다.
단점
Busy Waiting(바쁜 대기)
Spin lock이라고 불리는 Semaphore 초기 버전에서 Critical Section 에 진입해야하는 프로세스는 진입 코드를 계속 반복 실행해야 하며, CPU 시간을 낭비했었다. 이를 Busy Waiting이라고 부르며, Critical Section이 짧으면서 자주 발생해서 Context Change 오버헤드가 더 클 때가 아니면 비효율적이다.
일반적으로는 Critical Section에 진입을 시도했지만 실패한 프로세스에 대해 Block시킨 뒤, Critical Section에 자리가 날 때 다시 깨우는 방식을 Semaphore에서 사용한다. 이 경우에는 Busy waiting으로 인한 시간낭비 문제가 해결된다.
좋은 정보 모아주셔서 정말 감사합니다. 많은 도움 되었습니다.
Reference
https://en.wikibooks.org/wiki/Operating_System_Design/Processes/Semaphores
https://ko.wikipedia.org/wiki/%EC%84%B8%EB%A7%88%ED%8F%AC%EC%96%B4
https://en.wikipedia.org/wiki/Spinlock
https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%95%80%EB%9D%BD