![우선순위가 낮은 스레드가 우선순위가 높은 스레드를 차단하는 것 같습니까? [폐쇄]](https://linux55.com/image/118759/%EC%9A%B0%EC%84%A0%EC%88%9C%EC%9C%84%EA%B0%80%20%EB%82%AE%EC%9D%80%20%EC%8A%A4%EB%A0%88%EB%93%9C%EA%B0%80%20%EC%9A%B0%EC%84%A0%EC%88%9C%EC%9C%84%EA%B0%80%20%EB%86%92%EC%9D%80%20%EC%8A%A4%EB%A0%88%EB%93%9C%EB%A5%BC%20%EC%B0%A8%EB%8B%A8%ED%95%98%EB%8A%94%20%EA%B2%83%20%EA%B0%99%EC%8A%B5%EB%8B%88%EA%B9%8C%3F%20%5B%ED%8F%90%EC%87%84%5D.png)
2개의 스레드가 있는데 각 스레드는 SCHED_FIFO를 사용하여 서로 다른 실시간 우선순위로 설정됩니다. 스레드 조절이 비활성화되었으므로 이론적으로 가장 높은 우선순위 스레드는 CPU 리소스를 100% 사용할 수 있어야 하며, 낮은 우선순위 스레드가 실행되는 것을 방지해야 합니다. 양보하거나 절전 모드로 전환하지 않는 낮은 우선순위 스레드에서 긴밀한 무한 루프를 생성하면 우선순위가 낮은 스레드가 실행될 것으로 예상되지 않습니다. 그러나 우선 순위가 더 높은 스레드의 표준 출력도 정지되어 실행이 차단된 것으로 나타나 혼란스럽습니다.
우선순위가 낮은 스레드가 항상 우선순위를 가져야 하는 우선순위가 높은 스레드를 방해하는 이유는 무엇입니까? 긴밀한 무한 루프와 관련이 있습니까? 아니면 Linux 스레드 우선 순위가 어떻게 작동해야 하는지 근본적으로 오해하고 있습니까?
질문을 가능한 한 일반적으로 만들려고 노력했지만 답변이 내 특정 설정과 관련이 있을 수 있으므로 ARMV7 CPU에서 실행되는 RT Preempt 패치와 함께 커널 버전 4.1.33을 사용하고 있습니다.
편집하다:
아무런 문제 없이 문제를 재현하기 위해 매우 간단한 테스트 프로그램을 만들었고, 예상대로 문제가 사라졌습니다. 이는 일부 공유 리소스가 더 높은 우선순위 스레드의 실행을 방해할 수 있음을 나타냅니다(아래 설명에서 제안한 대로). 그러나 우선 순위가 더 높은 스레드가 액세스해야 하는 리소스는 생각나지 않습니다.
현재 내 문제 중 하나는 어떤 유형의 리소스에 배타적 잠금이 필요한지 확실하지 않다는 것입니다. 시스템 시계 액세스, 파일 시스템 액세스 또는 stdout 액세스와 같은 작업은 잠금 사용에 대해 잘 모르겠습니다. 이 중 어떤 것(또는 내가 간과하고 있는 유사한 것)이 더 높은 우선순위 스레드의 실행을 방해할 수 있습니까?
답변1
Linux 시스템에서는 애플리케이션이 실행되고 있지 않으면 "ktimersoftd" 스레드가 가장 높은 우선순위를 가지며 실시간 우선순위는 1입니다. 그러나 우리가 사용하는 애플리케이션과 타사 라이브러리는 모두 "ktimersoftd"를 선점하는 더 높은 우선순위의 실시간 스레드를 생성합니다. 우리가 사용한 타사 라이브러리 중 하나는 "ktimersoftd" 스레드가 타사 라이브러리의 스레드보다 더 높은 우선 순위를 갖도록 요구하는 Softirq에 의존하는 것으로 나타났습니다. "ktimersoftd" 스레드의 우선순위를 실시간 우선순위 98로 높이면 우리가 보고 있던 문제가 해결되었습니다.