이는 스레드의 경우 100% 정상입니다.모든 운영 체제. 스레딩 라이브러리의 문서, 찾을 수 있는 예제 및 튜토리얼 등은 이를 강조할 것입니다. 이는 사람들이 스레딩 방법을 배울 때 종종 혼란을 줄 수 있기 때문입니다.

스레드가 기본값입니다(정의에 따라).동기화되지 않음.

이는 잠금, 세마포어 등을 통해 반대 방향으로 배열하지 않는 한 스레드가 특정 순서로 실행될 것이라고 기대하지 않음을 의미합니다. 그들이 무엇을 하는지, 당신이 어떻게 하는지는 중요하지 않습니다.생각하다그들이 무엇을 하고 있는지 등에 따라 "일어날 수도 있습니다". 간단히 말해서, 그들을 이런 식으로 생각하지 마십시오. 그것은 그들의 존재도 아니고 그들의 목적도 아닙니다. "나는 단일 사용자 모드에 있고 시스템을 물처럼 가만히 만들려고 노력 중입니다. 왜냐면... 어쩌고 저쩌고"와 같은 생각을 떠올리는 것은 시간 낭비이고 배울 것이 없습니다. . 물은 피할 수 없다아직은 아니야, 액체는 이렇습니다. 이야기의 끝. 계속해서 즐기십시오.

말씀하신 대로 거의 아무것도 하지 않도록 설정한 시스템에서 거의 아무것도 하지 않는 스레드가 있으면 스케줄러의 로드가 줄어들지만 CPU는 여전히 최고 속도로 실행되고 있으며 거의 ​​아무 것도 하지 않는 일이 빠르게 발생한다는 점에 유의하세요. 상황이 반드시 다른 어떤 상황보다 더 예측 가능한 것은 아닙니다. 스케줄러는 스레드와 프로세스의 순서를 동기적으로 또는 예측 가능하게 지정하도록 설계되지 않았습니다. 저는 제가 말하는 내용이 여러분이 더 복잡하고 의사논리적인 실험을 하도록 영감을 주지 않기를 진심으로 바랍니다. 왜냐하면 이미 말했듯이,시간 낭비입니다. 계속 진행하세요.

너할 수 있는그리고 그것들을 동기화하는 것이 가능합니다. 그러나 이것은 그들이 단지 "자연스럽게" 하지 않는 이유를 먼저 이해하도록 요구하는 미묘한 속임수라는 점을 명심하십시오(단서: 그들은 그것을 할 이유가 없기 때문에 그것을 하지 않습니다) ).

“결정론적 운영 체제를 만드는 이유~인 것 같다불확실성? "

아마도 유체 역학 비유는 결국 그렇게 어리석은 것이 아닐 수도 있습니다. 체액~인 것 같다카오스 - 연기가 살아있는 것처럼 보입니다. 저는 수학, 유체역학, 카오스 이론에 대한 연구를 믿습니다.십자가. 그러나 대부분의 사람들은 아마도 이것에 충격을 받지 않을 것입니다("굉장해요! 자연 현상에서 무엇이 그러한 행동을 유발할 수 있습니까? 어쩌면 그것은 신의 증거일 수도 있습니다!"... 아니요). ) 유체 역학과 상호 작용)특정 범위 내에서 관찰대략적으로만 예측할 수 있는 결과("좋아, 물이 유리잔에서 쏟아질 것이다...")가 생성되므로 실제로는 혼란스럽거나 불확실합니다(테이블에 물이 튀는 패턴). 단지 "아주 작은 불"이나 물 한 잔일지라도 우리는 그 움직임에 수조 개의 입자가 관련되어 있음을 인식합니다.

컴퓨터가 얼마나 빨리 계산할 수 있는지 확인하기 위해 카운터를 반복하면서 바쁘게 본 적이 있다면 다음과 같은 순서라는 것을 알게 될 것입니다.수십억초당 횟수. "유휴" 시스템에서도 계속 발생하는 대부분의 "사소한" 시스템 이벤트는 인쇄 ID로 활동이 측정되는 스레드보다 훨씬 더 중요하다는 점을 명심하세요(그렇다면)모든 스레드가 수행 중. 유동적 비유에 따르면, "완전히 바람이 없는" 날이라고 생각하는 날에도 연기는 여전히 질서정연한 기둥을 형성하지 않습니다(그러나 자체 움직임이 연기에 어떻게 영향을 미치는지 더 명확하게 볼 수 있습니다).

스케줄러는 각 프로세스에 한 번에 정확히 1나노초를 제공하는 대신(이렇게 하면 실험을 더 예측 가능하게 만들 수 있음) 모든 프로세스가 균형 잡힌 방식으로 실행되도록 해야 합니다(중력으로 인해 물이 넘칠 수 있음). 스케줄러의 역할은 아무것도 동기화하는 것이 아니라 모든 일이 적절하게 균형 잡힌 방식으로 발생하도록 하는 것이기 때문에 이것은 모두 괜찮습니다. 이 두 가지 목표는 동일하지 않습니다. 실제로 동기화를 시작하면 동기화가 확실한 균형을 이룰 수 있지만 효율성이 떨어지게 된다는 사실을 알게 될 것입니다.

또한 Linux 스케줄러는 다음을 사용합니다.레드 블랙 트리대기열을 정리하기 위해서는 단순히페이루오라인(현대적인 범용 스케줄러가 이 작업을 수행할지는 의심스럽습니다). 이것은 의미한다더 큰 복잡성그러므로 더 많은확실히혼란스러운 행동.

나는 당신이 집착을 고수하도록 격려하고 싶지 않지만 스레드에게 더 실질적인 작업을 수행하도록 요청하면 실제로 스레드가 다음과 같은 작업을 수행하도록 할 것입니다.시간이를 수행하고 유휴 시스템에서 몇 초의 시간 오프셋을 두고 실행하면 실제로 완전히 결정적인 결과를 볼 수 있습니다. 이것만 기억하세요아니요정말 효과적인 동기화 수단 --바람이 불고 물이 넘치면 혼돈이 시작되는 것을 볼 수 있습니다 ;)

"이러한 이벤트가 운영 체제 스케줄러에 미치는 영향을 조사한 연구를 알고 계십니까?"

아니요, 액체처럼 신비한 것이 전혀 없기 때문입니다. 스케줄러는 실제로 완전히 결정적이지만 고려 중인 의미나 규모가 아닙니다. 커널 코드에 많은 정보를 넣고 printk스케줄러의 알고리즘을 이해하면 불확실성을 찾을 수 없습니다. 모든 것이 예상대로 발생합니다.

소프트웨어는 하드웨어보다 더 결정적일 수 없습니다. 첫째, 다양한 소스(예: 마우스, 키보드, 네트워크, 시계, 저장소, OS 백그라운드 작업)에서 무작위로 인터럽트가 발생합니다.

프로그램 실행 중에 이러한 인터럽트가 완전히 비활성화된 경우에도 80486 및 최신 범용 x86 데스크탑 하드웨어는 상당히 비결정적인 실행 순서를 갖습니다. (따라서 일반적으로 많은 실시간 작업에 부적합하므로 Pentium 1과 2가 출시된 지 오랜 후에도 80386이 2007년에도 계속 생산되었습니다.) 합리적인 비용으로 처리량을 얻으려면 하드웨어 결정론을 희생해야 합니다. 이는 캐시 효과, 동시 멀티스레딩(하이퍼스레딩), 분기 예측, 비순차적 실행 및 파이프라이닝으로 인해 발생합니다. 결정론적 동작은 8비트 Arduino가 훨씬 빠른 Raspberry-Pi보다 정밀한 기계 제어에 더 적합한 이유입니다.

기본적으로 Mainline Linux는 대화형 작업에 대해 우수한 전체 처리량과 우수한 평균 대기 시간을 달성하도록 설계된 범용 스케줄러가 포함된 범용 운영 체제입니다. 메인라인은 대기 시간 제한과 적절한 순서가 필요하지만 드물게 발생하는 예상치 못한 상황을 허용할 수 있는 화상 통화와 같은 "소프트 실시간" 예약과 함께 사용할 수도 있습니다.

완전히 선점 가능한 하드 실시간 Linux 커널을 만들기 위한 실시간 패치가 있습니다. (커널 스레드도 사용자 작업을 위해 선점/지연/중단될 수 있습니다.) 이를 통해 작업 대기 시간을 편향 한계로 제한할 수 있습니다. 하드웨어. 이러한 엄격한 제한 요구 사항은 종종 하드웨어의 효과적인 활용을 감소시키고 운영 체제의 동작을 변경합니다. (이것은 주차장에서 일부 주차 공간을 예약하는 것과 같습니다. 최대 평균 차량 수는 줄어들지만 이제 주차 공간을 예약하는 사용자에게는 주차 시간이 고정됩니다.) 전문적인 음악 녹음, 기계 제어, 뱅킹에는 RTL 코어가 선호됩니다. 거래, 정밀 센서 데이터 샘플링, 의료 장비 등 하드웨어 선택은 개발 고려 사항의 핵심 부분입니다. 특히 필요한 최대(평균, 중앙값 또는 모드 아님) 지연 분산(총 지연 아님)이 약 500,000 클럭 사이클 미만이어야 하는 경우 더욱 그렇습니다.

일반적인 범용 Linux 스케줄러의 경우. 작업의 기본 예약은 CPU 로드 및 실제 작업 동작을 기반으로 런타임 시 우선순위를 약간 조정하는 동적 우선순위를 사용합니다. 실제 CPU 로드 및 작업 동작에는 백그라운드 작업, 다양한 시작 상태(예: 실행 시작 시 캐시 조건) 및 무작위 오류(예: 작업이 승리하거나 패배하게 만드는 허위 인터럽트 요청)로 인해 많은 변수가 포함됩니다. 경주). 다음 타임 슬라이스 및 그에 따른 스케줄링 캐스케이드 효과. )

저는 8비트 초기부터 PC를 사용해 왔으며 많은 프로그래밍 언어에 익숙합니다. 저는 Mint Cinnamon의 운영 체제가 작동해야 하는 작업을 수행한 후 백그라운드에서 운영 체제의 더 깊은 기능을 망칠 수 있는 작업을 수행한다는 사실을 몇 번이고 발견했습니다. 재부팅하면 일반적으로 도움이 되지만 항상 그런 것은 아닙니다. 결국 Windows가 더 나은 것은 아니지만 시스템이 제공하는 변경 옵션을 변경한 후 어떤 일이 발생하는지 더 예측 가능하다고 말해야 합니다. 과거 테스트에 익숙하기 때문에 Mint가 올바른 방식으로 테스트되지 않았다고 생각합니다.