일반 작업자 스레드는 대기열에서 사용 가능한 작업을 확인하고 소비하는 루프에서 실행됩니다. 스레드가 사용 가능한 작업이 없을 때 몇 밀리 초 동안 기다리는 예제가 있는데, 예를 들어 std::this_thread::sleep_for()을 사용합니다. 그러나, 스레드가 최소한의 대기 시간으로 작업을 소비하기를 원하기 때문에 잠을 자지 않습니다. 그게 나쁜거야? 작업을 확인할 때 몇 밀리 초 동안 작업자 스레드가 잠자기해야합니까?작업자 스레드가 잠자기해야합니까?
"롤 자신의"대기열 또는 메시지 시스템, 100 % CPU를 소모하지 않도록하는 한 가지 방법은 사용할 수있는 작업이 없을 때 조금 "잠"것입니다. 그러나 OS가 (세마포어, 파이프 또는 메일 시스템과 같은 OS 기반 큐 또는 네트워크 메시지 전달 메커니즘을 사용하는 등) OS를 처리 할 수있게 해주는 다른 메커니즘을 사용하는 것이 훨씬 낫습니다. 응용 프로그램을 단순화하고 OS가 잠자기/깨우기 처리를 처리하도록합니다.
물론, 실제로 무엇을 성취하려고하는지, 그리고 기대치가 무엇인지에 달려 있습니다. 예를 들어 휴대 전화에서 코드를 실행하려고하면 CPU주기를 낭비하지 않아도됩니다. 배터리 수명뿐만 아니라 다른 작업에서 사용할 수있는 CPU 사이클 낭비가 있습니다. 다른 한편, 메시징 시스템이 자동차의 ABS 브레이크에 있고 서브 마이크로 초 정도의 정확도로 센서의 펄스 시간을 측정해야하는 경우 잠자기는 코드가 잠자기 상태가 될 것이므로 나쁜 생각입니다. ABS 센서의 펄스보다 한 번 이상 많이 걸립니다.
데스크톱에있는 경우 몇 초 또는 1 분 이상 실행해도 응용 프로그램이 절전 모드로 전환되지 않으면 아무도 신경 쓰지 않습니다. 그러나 1 시간 동안 100 % 1 코어를 계속 사용한다면 (앱이 낭비되는 사이클만큼 가치가있는 것을 생산하지 못합니다. 분명히 세계에서 다음으로 큰 소수를 계산하거나 단백질을 접는 것은 아마도 인터넷에서 패킷을 수신 할 때 0.5 밀리 초를 절약하는 것은 아닙니다.
귀하 (그리고 프로젝트에 참여한 다른 모든 사람들)만이 프로젝트의 설계 기준이 무엇인지 알 수 있습니다. 그것은 당신이 "인터넷에 물어볼 수있는"것이 아닙니다. 그러나 위의 내용은 설계 기준이 무엇인지 파악한 후에 지침을 제공합니다.
스레드를 잠자 지 않고 초당 수백만 개의 검사로 CPU 사이클을 낭비 할 수 있으므로 너무 좋지 않은 수표에만 CPU 코어 전체를 사용할 수 있습니다. –
전략은 응용 프로그램의 처리 확장 성을 향상시키는 것이라고 생각합니다. 작업자 스레드가 "너무 빨리"차단할 때 상황 전환을 피할 수 있습니다. 이 전략을 사용하면 작업자 스레드가 일부 작업이 나타나고 작업자 스레드가 컨텍스트 전환을 일으키지 않기를 바라는 가운데 약간 잠자기 상태가됩니다. 그러나 앱 작성자 이후에 예상되는 워크 플로로 이러한 모든 가정을 검증 할 수 있습니다. –
대기열에 문제가 없으면 대기열이 비어있는 동안 절전 모드 (대기열 소비 없음, 대기 중 대기 없음)가 발생하고 작업량이 많을 때 조건 변수를 통해 즉시 깨우는 "수신 대기"작업이 있어야합니다 대기. – delnan