답변:
병목 현상이 CPU 자체 인 경우 우선 순위는 도움이되지 않습니다. 대부분의 시스템에는 모든 프로세스를 연속적으로 실행할 프로세서가 충분하지 않기 때문에 운영 체제가 다음에 실행할 프로세스를 결정하기 위해 사용 하는 스케줄링 알고리즘에 실제로 우선 순위 가 있습니다.
우선 순위가 높은 작업은 대기열의 맨 위로 빠르게 이동하므로 일반적인 대기 시간에 도움이되지만 프로세스가 전체 시간 조각을 소진하는 경우 실제 계산에 할당 된 경우 일정이 변경되지 않습니다. 우선 순위를 변경하는 것은 I / O를 기다리는 프로세스가 있고보다 빠른 응답을 원할 때 더 유용합니다.
우선 순위는 사용 가능한 CPU 코어보다 실행 가능한 스레드가 더 많은 경우에만 중요합니다. 이 경우 우선 순위는 어떤 스레드를 실행할지 제어합니다. 대부분의 시스템에서 CPU의 경합에 대해 충분한 계산이 이루어지지 않습니다. 스레드가 모두 차단 되어 어떤 일이 발생하기를 기다립니다. 무언가를 입력하거나, 마우스를 움직이거나, 화면을 터치하거나, 디스크, 네트워크, 연결 한 다른 장치 또는 중요한 스레드에 대한 작업을 마치기 위해 다른 스레드에서 데이터가 도착하기를 기다리는 것일 수 있습니다. 구조. 프로그램의 일부를 디스크에서 읽거나 파일을 명시 적으로 읽는 대신 다시 읽기 위해 스왑 된 일부 메모리에서 대기 중일 수 있습니다.
Windows에서 스케줄러 는 각 우선 순위 레벨에서 실행 가능한 스레드 큐를 유지 합니다. 스레드가 퀀텀 을 소진했거나 (다른 것을 실행하기 전에 허용 된 시간) 스레드를 예약해야하거나 스레드가 차단되어 더 이상 실행할 수 없거나 더 높은 우선 순위 를 갖도록 스케줄링 결정을 내릴 때 스레드가 차단 해제되었습니다. 실행 가능한 스레드가있는 우선 순위가 가장 높은 큐의 다음 스레드가 스케줄됩니다. 실행중인 스레드가 양자를 모두 사용한 경우 큐의 끝에 놓입니다. 우선 순위 수준에서 실행 가능한 유일한 스레드이고 우선 순위가 높은 다른 실행 가능한 스레드는 없지만 실행되지 않는 스레드가 있으면 다른 방향으로 전환됩니다.
멀티 코어 / 멀티 프로세서 시스템에서는 스레드가 실행될 수있는 코어에 제한이있을 수 있습니다. 또한 시스템 은 스레드의 데이터가 해당 코어의 캐시에있을 가능성이 높고 작성된 데이터에 빠르게 액세스 할 수 있도록 이상적인 코어 및 NUMA 노드 내에 스레드를 유지하려고합니다 . 다음에 실행할 항목을 선택하지 않으면 스레드가 비 이상적인 코어에서 계속 실행됩니다.
이 시스템은 다양한 동적 우선 순위 부스트 및 동적 양자 크기를 사용하여 포 그라운드 애플리케이션이 백그라운드 프로세스보다 더 많은 시간 (필요한 경우)을 얻고 I / O 작업이 완료 될 때 (마우스, 키보드 및 터치 스크린 입력). 또한 우선 순위 강화는 우선 순위가 높은 스레드가 현재 보유하고있는 리소스를 기다리는 우선 순위 반전을 방지하는 데 사용됩니다. 중간 우선 순위 스레드도 실행중인 경우 우선 순위가 낮은 프로세서 시간이 부족하여 우선 순위가 높은 스레드를 유지합니다. 따라서 우선 순위가 낮은 스레드가 일시적으로 우선 순위가 높아 지므로 시간이 걸리고 우선 순위가 높은 스레드에 필요한 리소스가 해제됩니다.
Windows Vista 이전에는 스레드 우선 순위가 I / O 작업 완료 속도에 영향 을 미치지 않았습니다. Windows Vista부터 I / O도 우선 순위를 가질 수 있으며 기본적으로 스레드 우선 순위에서 비롯됩니다.
요약 : CPU가 많이로드되지 않으면 스레드 우선 순위를 변경해도 아무런 영향을 미치지 않으며, 그 영향도 일반적으로 최소화됩니다. 프로세스가 I / O를 기다려야하거나 CPU 시간 동안 다른 프로세스와 충돌하지 않는 경우 이미 가장 빠른 속도로 실행 중이며 우선 순위를 변경해도 더 빠르지는 않습니다.
I / O 바운드 프로세스의 I / O 우선 순위를 높이더라도 프로세스가 더 빨리 실행되는 것은 아닙니다. 예를 들어, 별도의 원격 프로세스에 의해 생성 된 데이터 소비자이고 해당 소스가 데이터를 생성하는 속도를 따라가는 경우 더 빠르거나 더 높은 처리량을 가질 수 없습니다.
Mike Dimmick의 답변에서 설명한 것처럼 현재 허용되는 답변의 첫 번째 문장 ( /superuser//a/752587/322588 ) 에서 명시 적으로 언급 한 내용과 달리 우선 순위 변경은 CPU가 병목 현상 일 때 가장 효과적입니다. ( /superuser//a/752864/322588 ). 또한 수락 된 답변의 두 번째 단락의 "프로세스가 전체 시간 조각을 소진하면 실제 계산에 할당 된 경우 예약이 변경되지 않습니다"라는 문장은 프로세스가 일반적으로 모든 우선 순위가 가장 높지 않은 한 완전히 잘못되었습니다 실행될 때마다 실행 가능한 스레드. 다른 모든 상황에서 우선 순위를 높이면 벽시계 간격 당 더 많은 시간이 걸리기 때문입니다.
Mike Dimmick은 며칠 전에이 답변의 문제점을 지적하고 훨씬 더 나은 답변을 제공했지만 첫 번째로 설명 할 수없는 투표를 계속하고 있습니다. 저자가 단지 우리에게 인형에 대한 그의 답을 바보라고 주장하는 것은 그것이 CPU 바운드 프로세스와 관련하여 단순히 단순하거나 단순하지도 않기 때문에 헛된 것이 아니기 때문에 그럴듯하지 않다.
면책 조항 : Dimmick 씨는 모르지만 자신이 무엇을 쓰고 있는지 알 수 있습니다.
timeBeginPeriod (...)인터랙티브 한 모든 것을하는을 호출 할 수 있습니다 . 게임은 일반적으로 시작될 때 이것을 1로 설정 하며, 보드에서 1ms의 예약 간격을 시스템에서 실행되는 모든 것에 적용합니다. 그것을 한 프로세스에만 국한되지 않습니다. 멀티 태스킹을 위해 Windows를 진지하게 받아들이지 않는 이유 중 하나입니다.