대부분의 뮤텍스 구현이 왜 불공평합니까?

나의 이해는 그 뮤텍스의 가장 인기 구현 (예 : 표준 : : C ++에서 뮤텍스)하지 보증 할 공정성을 - 즉, 그들은 보증하지 않습니다 경합의 경우에, 잠금이 순서대로 스레드에 의해 인수 될 것을 그들이 lock ()이라고합니다. 실제로, 경합이 많은 경우, 뮤텍스를 얻기 위해 대기중인 일부 스레드가 절대로이를 획득 하지 못할 수도 있습니다 (희망적이지는 않지만) .

이것은 나에게 도움이되지 않는 행동처럼 보입니다. 공정한 뮤텍스가 프로그래머가 원하거나 기대하는 것에 따라 행동을 더 많이 낳을 것 같습니다.

뮤텍스가 일반적으로 공정하게 구현되지 않은 이유는 "성능"이지만, 이것이 의미하는 바, 특히 뮤텍스의 공정성 요구를 완화하는 것이 성능을 어떻게 향상시키는 지 더 잘 이해하고 싶습니다. "공평한"뮤텍스는 구현하기가 쉽지 않은 것 같습니다. 스레드를 휴면 상태로 만들기 전에 lock ()을 호출하여 뮤텍스의 링크 된 목록의 꼬리 부분에 추가 한 다음 unlock ()을 다음 스레드에서 같은 목록의 머리와 깨우십시오.

여기서 내가 놓친 뮤텍스 구현 통찰력은 무엇입니까?

Jim Sawyer의 답변은 하나의 답변을 가리 킵니다. 우선 순위가 다른 스레드가 있으면 "공정한"동작이 올바르지 않습니다. 실행할 수있는 스레드가 여러 개인 경우 우선 순위가 가장 높은 스레드가 일반적으로 실행되어야합니다.

그러나 운영 체제 구현에 대한 약간의 비밀이 있습니다. 운영 체제는 때때로 사용자 스레드를 하이재킹하여 사용자로서 코드를 실행한다는 것입니다. 안전상의 이유로이 작업을 수행하는 대부분의 운영 체제는 스레드가 차단 된 상태에서만 작동합니다. 운영 체제가 완료되면 스레드가 다시 일시 중단되며 이는 일반적으로 스레드를 대기 큐의 뒷면으로 이동시키는 효과가 있습니다.

일반적인 예는 Unix의 신호 처리기, VMS의 비동기 시스템 트랩 또는 Windows NT의 비동기 프로 시저 호출입니다. 운영 체제는 사용자 프로세스에 이벤트가 발생했음을 알리고 사용자 공간에서 코드를 실행하여 처리됩니다.

비동기 I / O와 같은 많은 운영 체제 서비스가 종종이 기능 위에 구현됩니다.

또 다른 예는 프로세스가 디버거의 제어를받는 경우입니다. 이 경우, 디버깅 시스템은 다양한 이유로 사용자 작업으로서 코드를 실행할 수있다.

'우선 순위 반전'은 공정성이 바람직하지 않은 이유 중 하나입니다. 우선 순위가 낮은 프로세스는 잠긴 뮤텍스에 충돌하여 대기합니다. 그런 다음 우선 순위가 높은 프로세스가 프로세스를 시작하고 잠자기 상태가됩니다. 뮤텍스가 잠금 해제되면 다음에 어떤 프로세스가 잠금을 받아야합니까?

공정한 뮤텍스는 불공정 한 뮤텍스보다 평생 동안 더 많은 시간을 할애 할 것입니다. 불공정 한 뮤텍스를 해제하는 스레드는 항상 잠금을 해제 할 수 있기 때문입니다. 그러나 공정한 뮤텍스를 해제하는 스레드는 웨이터 큐가 비어있을 때만 잠금을 해제 할 수 있습니다. 그렇지 않으면, 해제 스레드는 다음 스레드를 위해 뮤텍스를 잠금 상태로 두어야합니다. 웨이터 큐의 첫 번째 스레드는 대기열에서 해제되어 해제됩니다. 뮤텍스는 새로 깨어 난 스레드가 CPU에서 예약 될 때까지 잠금 상태를 유지합니다. 현재 실행 가능한 스레드가 많은 경우 오랜 시간이 걸릴 수 있습니다.

해제 스레드가 즉시 동일한 뮤텍스를 다시 확보하려고 시도하면 대기 큐의 뒷면에 자신을 넣고 잠자기 상태로 만들어야합니다. 스레드가 처음에 뮤텍스를 해제하지 않은 경우에는 발생하지 않았을 것입니다. 그러므로 이것은 더 긴 "더 탐욕스러운"비판적 섹션을 장려합니다.