PTHREAD_MUTEX_ADAPTIVE_NP란 무엇입니까?

PTHREAD_MUTEX_ADAPTIVE_NP란 무엇입니까?

"적응형" pthread 음소거에 대한 설명서는 어디서 찾을 수 있습니까?PTHREAD_MUTEX_ADAPTIVE_NP 기호는 시스템에 정의되어 있지만 온라인에서 찾을 수 있는 유일한 설명서에는 적응형 뮤텍스가 무엇인지 또는 언제 사용하는 것이 적절한지에 대한 설명이 없습니다.

그럼... 뭐죠? 그리고 언제 사용해야 하죠?

참고로 제 libc 버전은 다음과 같습니다.

GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu10.5) stable release version 2.15, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.6.3.
Compiled on a Linux 3.2.50 system on 2013-09-30.
Available extensions:
    crypt add-on version 2.1 by Michael Glad and others
    GNU Libidn by Simon Josefsson
    Native POSIX Threads Library by Ulrich Drepper et al
    BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

그리고 "unname-a"는

Linux desktop 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

PTHREAD_MUTEX_ADAPTIVE_NP리눅스 스레드를 보다 안정적으로 만들고 성능을 향상시키기 위해 glibc 기여자 역할을 하면서 발명한 것입니다.리눅스 스레드는 OCaml의 창시자 중 한 명으로도 잘 알려진 자비에 르로이에 의해 독립형 라이브러리로 개발된 glibc의 NPTL 라이브러리의 전신이었습니다.

적응형 뮤텍스는 본질적으로 수정되지 않은 형태로 NTPL로 살아남았습니다. 코드는 추정기 평활화에 대한 마법 상수와 추정기에 대한 최대 스핀을 포함하여 거의 동일합니다.

SMP 하에서 뮤텍스를 획득하려고 할 때 그것이 잠겨 있는 것을 볼 때, 단순히 포기하고 차단하기 위해 커널로 호출하는 것이 차선의 방법이 될 수 있습니다.만일 자물쇠의 소유자가 단지 몇 가지 명령만을 위해 자물쇠를 잡고 있다면, 단지 그 명령들의 실행을 기다렸다가, 시스템 호출을 함으로써 수백 번의 추가적인 주기를 소비하는 대신, 원자력 작동으로 자물쇠를 획득하는 것이 더 저렴합니다.

커널 개발자들은 이 사실을 잘 알고 있는데, 이것이 바로 리눅스 커널에 빠른 중요 섹션을 위한 스핀락이 존재하는 이유 중 하나입니다. (물론 다른 이유들 중 하나는 인터럽트 상황에 있기 때문에 잠을 잘 수 없는 코드가 스핀락을 획득할 수 있기 때문입니다.)

문제는 얼마나 기다려야 하느냐 입니다.잠금을 획득할 때까지 영원히 회전하면 차선책이 될 수 있습니다.사용자 공간 프로그램은 커널 코드(기침)처럼 잘 쓰이지 않습니다.중요한 부분이 길 수도 있습니다.또한 프리엠프션을 비활성화할 수 없습니다. 컨텍스트 스위치로 인해 중요한 섹션이 폭발하기도 합니다. (이제 POSIX 스레드는 이 문제를 해결하기 위한 실시간 도구를 제공합니다. 실시간 우선 순위 및 FIFO 스케줄링 등에 스레드를 넣을 수 있으며 프로세서 친화도를 구성할 수 있습니다.)

제 생각에 우리는 고정된 반복 횟수를 가지고 실험을 해보았지만, 저는 이런 생각이 들었습니다. 우리가 언제 측정할 수 있는지 추측해야 하는 이유는 무엇일까요.TCP 재전송 타임아웃(RTO) 추정기에 대해 수행하는 것과 유사하게 잠금 지속 시간의 평활화 추정기를 구현하는 것은 어떨까요?우리가 자물쇠를 돌릴 때마다, 우리는 그것을 얻기 위해 실제로 얼마나 많은 스핀이 필요했는지를 측정해야 합니다.또한 영원히 회전해서는 안 됩니다. 현재 추정치의 최대 두 배만 회전해야 합니다.할는 몇 할 수 값의 그 를 들어,때,다입니다. 이전 값의 일부와 새로운 값의 일부를 취하여 이들을 더하면 이는 그 차이의 일부를 다시 추정량에 추가하는 것과 같습니다. 예를 들어,estimator += (new_val - estimator)/8기존 값과 새 값 사이의 1/8에서 7/8 혼합 값의 경우.

이것은 감시자라고 생각하시면 됩니다.추정기가 잠금을 획득하는 데 평균적으로 80개의 스핀이 소요된다고 가정합니다.그렇다면 160개의 스핀을 실행했다면 뭔가 잘못된 것이 있다는 것을 확신할 수 있습니다. 잠금의 소유자가 예외적으로 긴 경우를 실행하고 있거나, 페이지 오류에 부딪혔거나, 그렇지 않은 경우 선점되었을 수 있습니다.이 시점에서 대기 스레드는 손실을 줄이고 커널에 호출하여 차단합니다.

측정하지 않으면 이 작업을 정확하게 수행할 수 없습니다. "하나의 크기가 모두 적합" 값이 없습니다.예를 들어, 임계 구간이 너무 짧아 거의 항상 10회만 기다린 후 잠금을 가져올 수 있는 프로그램에서는 200회로 고정된 제한이 차선일 것입니다.뮤텍스 잠금 기능은 20번 정도의 주기를 잘 포기하고 절약하는 대신 비정상적인 대기 시간이 있을 때마다 200번의 반복 연소를 거치게 됩니다.

이 적응형 접근 방식은 모든 프로그램의 모든 잠금에 대해 작동하지 않는다는 점에서 특수한 방식이므로 특수 뮤텍스 유형으로 패키지됩니다.예를 들어, 음소거를 장기간 잠그는 프로그램에서는 잘 작동하지 않습니다. 너무 긴 기간 동안 커널에 들어가는 것보다 더 많은 CPU 시간이 큰 추정치 값에서 회전하는 데 낭비됩니다.이 접근 방식은 또한 유니프로세서에 적합하지 않습니다. 잠금을 시도하는 스레드를 제외한 모든 스레드가 커널에서 중단됩니다.이 접근법은 공정성이 중요한 상황에서는 적합하지 않습니다. 기회주의적 잠금입니다.얼마나 많은 다른 스레드가 기다리고 있었는지, 얼마나 오래 기다리는지, 또는 그 우선 순위가 무엇인지에 상관없이, 새로운 스레드가 와서 자물쇠를 낚아챌 수 있습니다.

경쟁이 치열한 짧은 중요한 부분을 가진 매우 잘 작동하는 코드를 가지고 있고 SMP에서 더 나은 성능을 찾고 있다면 적응형 뮤텍스는 시도해 볼 만한 가치가 있습니다.

기호는 다음과 같습니다.

http://elias.rhi.hi.is/libc/Mutexes.html

"LinuxThreads는 "빠른" 뮤텍스의 경우 PTHREAD_MUTEX_ADAPTive_NP인 뮤텍스 유형, "재귀" 뮤텍스의 경우 PTHREAD_MUTEX_RECURUS_NP, PTHREAD_MUTEX_MUTEX_MUTEX_NP 중 하나만 지원합니다.TIMED_NP는 "timed" 음소거를, PTHREAD_MUTEX_ERRORCHECK_NP는 "error checking" 음소거를 나타냅니다.NP 접미사에서 알 수 있듯이, 이는 POSIX 표준에 대한 휴대용이 아닌 확장이므로 휴대용 프로그램에 사용해서는 안 됩니다.

mutex 유형은 스레드가 pthread_mutex_lock으로 이미 소유하고 있는 mutex를 잠그려고 할 경우 발생하는 동작을 결정합니다.뮤텍스가 "빠른" 유형이면 pthread_mutex_lock은 단순히 호출 스레드를 영원히 일시 중단합니다.뮤텍스가 "error checking" 유형이면 pthread_mutex_lock이 에러 코드 EDEDELK와 함께 즉시 반환됩니다.뮤텍스가 "재귀" 유형이면 pthread_mutex_lock 호출은 성공 반환 코드와 함께 즉시 반환됩니다.뮤텍스를 소유한 스레드가 잠근 횟수가 뮤텍스에 기록됩니다.소유 스레드는 동일한 횟수로 pthread_mutex_unlock을 호출해야 뮤텍스가 잠금 해제 상태로 돌아갑니다.

기본 뮤텍스 유형은 "timed", 즉 PTHREAD_MUTEX입니다.TIMED_NP."

편집: jthill에서 찾은 정보로 업데이트 (감사합니다!)

MUTEX 플래그와 PTHREAD_MUTEX_ADAPTIVE_NP에 대한 자세한 내용은 다음과 같습니다.

"PTHRED_MUTEX_ADAPTIVE_NP는 공정성과 고른 CPU 사이클을 희생하면서도 높은 처리량을 위해 고안된 새로운 뮤텍스입니다.이 뮤텍스는 소유권을 대기 스레드로 이전하는 것이 아니라 경쟁을 허용합니다.또한 SMP 커널에서 잠금 작업은 즉각적인 스케줄링 비용을 피하기 위해 회전을 사용하여 잠금을 재시도합니다."

이것은 기본적으로 다음을 제안합니다. 높은 처리량이 바람직한 경우 이러한 뮤텍스는 매우 특성상 스레드 로직에서 추가적인 고려가 필요한 구현이 가능합니다.이러한 속성을 사용하여 높은 처리량을 얻을 수 있는 알고리즘을 설계해야 합니다.실행 순서가 중요하지 않은 ("커널에서"가 아닌) 내부에서 로드 밸런싱을 수행하는 것입니다.

리눅스/유니닉스 멀티스레딩 프로그래밍을 위한 아주 좋은 책이 있었는데, 그 책의 이름은 나를 피합니다.찾으면 업데이트하겠습니다.

여기 있습니다.제가 읽어보니 경쟁금지 사건을 빨리 진행시키는 것 외에는 아무 것도 신경 쓰지 않는 잔인하게 단순한 뮤텍스입니다.

언급URL : https://stackoverflow.com/questions/19863734/what-is-pthread-mutex-adaptive-np