Linux 환경에서 어떤 작업으로 인해 스레드 전환이 발생할 수 있습니까?

Linux는 일대일 스레드 모델을 채택하며 사용자 스레드 전환과 커널 스레드 전환의 차이는 매우 작습니다. 동시에, 사용자가 자발적으로 사용자 스레드의 실행 권한(수율)을 포기함으로써 발생하는 오버헤드를 무시한다면 커널 스레드 전환의 오버헤드만 고려하면 됩니다. (추천 학습: linux 튜토리얼 )

, 여기서는 이해의 단순화를 돕기 위한 것입니다. 실제로 사용자 스레드 라이브러리는 사용자 스레드의 예약 및 동기화에 많은 작업을 수행하며 이 비용은 무시할 수 없습니다.

JVM이 Thread#yield()를 설명하는 것처럼: 기본 OS가 항복 의미를 지원하지 않는 경우 JVM은 사용자 스레드가 시간 조각이 끝날 때까지 회전하도록 허용하고 스레드는 수동적으로 전환되어 비슷한 효과.

스레드 전환의 원인

타임 슬라이스 회전

스레드 차단

스레드가 타임 슬라이스를 적극적으로 포기함

직접 오버헤드

직접 오버헤드는 스레드 전환 자체로 인해 발생하며 이는 불가피하며 반드시 발생합니다.

사용자 모드와 커널 모드 간 전환

스레드 전환은 커널 모드에서만 완료할 수 있습니다. 현재 사용자가 사용자 모드에 있는 경우 필연적으로 사용자 모드와 커널 모드 간 전환이 발생합니다. ("사용자 모드와 커널 모드 간 전환"에 드는 구체적인 비용은 얼마입니까???)

컨텍스트 전환

앞서 언급했듯이 스레드(또는 프로세스) (선택 사항) task_struct에 정보를 저장해야 합니다. 스레드를 전환할 때 커널에서 이전 스레드의 task_struct를 잘라내고 새 스레드를 잘라내어 컨텍스트 전환을 발생시켜야 합니다. 또한 레지스터, 프로그램 카운터, 스레드 스택(작업 스택, 데이터 스택 포함) 등을 전환하는 것도 필요합니다.

스레드 스케줄링 알고리즘

스레드 스케줄링 알고리즘은 스레드의 상태, 대기 조건 등을 관리해야 합니다. 우선순위에 따라 스케줄링되는 경우 우선순위 큐도 유지해야 합니다. 스레드 전환이 빈번한 경우 이 비용을 과소평가할 수 없습니다.

간접 오버헤드

간접 오버헤드는 직접 오버헤드의 부작용으로 시스템 구현과 사용자 코드 구현에 따라 다릅니다.

캐시 누락

🎜전환 프로세스에는 새로운 로직을 실행해야 합니다. 두 가지가 액세스하는 주소 공간이 유사하지 않으면 캐시 누락이 발생하며 구체적인 영향은 시스템 구현 및 사용자 코드 구현에 따라 다릅니다. 시스템의 캐시가 더 크면 캐시 미스의 영향을 줄일 수 있습니다. 사용자 스레드가 데이터에 액세스하는 주소 공간이 서로 가까우면 캐시 미스 비율 자체도 상대적으로 낮습니다. 🎜

위 내용은 Linux 환경에서 어떤 작업으로 인해 스레드 전환이 발생할 수 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!