휘발성이 멀티 스레드 C 또는 C ++ 프로그래밍에서 유용하지 않은 이유는 무엇입니까?

최근에 게시 한이 답변 에서 입증 된 것처럼 volatile멀티 스레드 프로그래밍 컨텍스트 의 유틸리티 (또는 부족)에 대해 혼란스러워하는 것 같습니다 .

내 이해는 이것입니다 : 변수가 액세스하는 코드 조각의 제어 흐름 외부에서 변수가 변경 될 때마다 변수는로 선언되어야합니다 volatile. 다른 스레드에 의해 수정 된 신호 처리기, I / O 레지스터 및 변수는 모두 이러한 상황을 구성합니다.

따라서 전역 int foo가 있고 foo하나의 스레드에서 읽고 다른 스레드에서 원자 적으로 설정 한 경우 (아마도 적절한 기계 명령어 사용) 읽기 스레드는 신호 처리기에 의해 조정 된 변수를 보는 것과 같은 방식 으로이 상황을 봅니다. 외부 하드웨어 조건에 의해 수정되므로 foo선언해야합니다 volatile(또는 멀티 스레드 상황의 경우 메모리 고정로드로 액세스하는 것이 더 나은 솔루션 일 수 있습니다).

어떻게 그리고 어디에서 틀렸습니까?

volatile다중 스레드 컨텍스트에서 문제 는 필요한 모든 보장을 제공하지 않는다는 것 입니다. 필요한 속성이 몇 개 있지만 전부는 아니기 때문에 volatile 혼자 의지 할 수는 없습니다 .

그러나 나머지 속성 에 사용해야하는 프리미티브 도 그 속성을 제공 volatile하므로 사실상 불필요합니다.

공유 데이터에 스레드로부터 안전하게 액세스하려면 다음을 보장해야합니다.

• 실제로 읽기 / 쓰기가 발생합니다 (컴파일러는 레지스터에 값을 저장하지 않고 나중에 나중에 주 메모리 업데이트를 연기하지 않습니다)
• 재주문이 발생하지 않습니다. volatile변수를 플래그로 사용하여 일부 데이터를 읽을 준비가되었는지 여부를 표시 한다고 가정하십시오 . 코드에서는 데이터를 준비한 후 플래그를 설정하기 만하면 모든 것이 잘 보입니다 . 그러나 명령이 재정렬되어 플래그가 먼저 설정되면 어떻게 될까요?

volatile첫 번째 포인트를 보장합니다. 또한 다른 휘발성 읽기 / 쓰기간에 재정렬이 발생하지 않도록합니다 . 모든 volatile메모리 액세스는 지정된 순서대로 수행됩니다. volatileI / O 레지스터 또는 메모리 매핑 된 하드웨어를 조작하기 위해 필요한 모든 것이지만, volatile객체가 비 휘발성 데이터에 대한 액세스를 동기화하는 데만 사용되는 멀티 스레드 코드에서는 도움이되지 않습니다 . 이러한 액세스는 여전히 액세스와 관련하여 재정렬 될 수 volatile있습니다.

재정렬을 방지하는 해결책은 메모리 배리어 를 사용하는 것입니다. 메모리 배리어 는 이 시점에서 메모리 액세스가 재정렬되지 않을 수 있음 을 컴파일러와 CPU에 모두 나타냅니다 . 휘발성 가변 액세스 주위에 이러한 장벽을 배치하면 비 휘발성 액세스도 휘발성 액세스에서 재정렬되지 않으므로 스레드 안전 코드를 작성할 수 있습니다.

그러나 메모리 장벽 도 매우 효과적으로 우리에게 우리가 만드는 자체가 필요로하는 모든 것을 제공, 대기중인 모든이 쓰기가 장벽에 도달하면 실행 / 읽기 수 있도록 volatile필요합니다. volatile한정자를 완전히 제거 할 수 있습니다 .

C ++ 11부터 원자 변수 ( std::atomic<T>)는 모든 관련 보증을 제공합니다.

Linux Kernel Documentation 에서 이것을 고려할 수도 있습니다 .

C 프로그래머들은 종종 현재 실행 스레드 외부에서 변수가 변경 될 수 있음을 의미하기 위해 일시적으로 변합니다. 결과적으로 공유 데이터 구조를 사용할 때 커널 코드에서 사용하려고하는 경우가 있습니다. 다시 말해, 그들은 휘발성 유형을 일종의 쉬운 원자 변수로 취급하는 것으로 알려져 있습니다. 커널 코드에서 휘발성을 사용하는 것은 거의 정확하지 않습니다. 이 문서는 이유를 설명합니다.

휘발성과 관련하여 이해해야 할 핵심은 그 목적이 최적화를 억제하는 것인데, 이는 실제로는 절대로 원하지 않는 것입니다. 커널에서, 원치 않는 동시 액세스로부터 공유 데이터 구조를 보호해야합니다. 이는 매우 다른 작업입니다. 원치 않는 동시성을 방지하는 프로세스는 거의 모든 최적화 관련 문제를보다 효율적으로 피할 수 있습니다.

휘발성과 마찬가지로 데이터에 동시에 액세스 할 수있는 커널 프리미티브 (스핀 록, 뮤텍스, 메모리 장벽 등)는 원하지 않는 최적화를 방지하도록 설계되었습니다. 그것들이 올바르게 사용된다면, 휘발성도 사용할 필요가 없습니다. 휘발성이 여전히 필요한 경우 코드에 버그가있을 수 있습니다. 올바르게 작성된 커널 코드에서 휘발성은 작업 속도를 늦추는 역할 만 할 수 있습니다.

일반적인 커널 코드 블록을 고려하십시오.

spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);

모든 코드가 잠금 규칙을 따르는 경우 the_lock이 유지되는 동안 shared_data의 값이 예기치 않게 변경 될 수 없습니다. 해당 데이터로 재생하려는 다른 코드는 잠금 대기 중입니다. spinlock 프리미티브는 메모리 배리어 역할을합니다. 명시 적으로 작성되었으므로 데이터 액세스가 최적화되지 않습니다. 따라서 컴파일러는 shared_data에 무엇이 있는지 알고 있다고 생각할 수 있지만 spin_lock () 호출은 메모리 장벽으로 작동하므로 알고있는 것을 잊게합니다. 해당 데이터에 액세스 할 때 최적화 문제가 없습니다.

shared_data가 휘발성으로 선언 된 경우 여전히 잠금이 필요합니다. 그러나 컴파일러가 다른 사람과 함께 작업 할 수 없다는 것을 알고 있으면 중요한 섹션 내 에서 shared_data에 대한 액세스를 최적화하지 못하게됩니다 . 잠금이 유지되는 동안 shared_data는 휘발성이 아닙니다. 공유 데이터를 처리 할 때 적절한 잠금은 불필요하고 잠재적으로 유해합니다.

휘발성 스토리지 클래스는 원래 메모리 매핑 된 I / O 레지스터를위한 것입니다. 커널 내에서 레지스터 액세스도 잠금으로 보호해야하지만 컴파일러는 중요한 섹션 내에서 레지스터 액세스를 "최적화"하기를 원하지 않습니다. 그러나 커널 내에서 I / O 메모리 액세스는 항상 접근 자 기능을 통해 수행됩니다. 포인터를 통해 I / O 메모리에 직접 액세스하는 것은 어리둥절하며 모든 아키텍처에서 작동하지는 않습니다. 이러한 접근자는 원치 않는 최적화를 방지하기 위해 작성되므로 휘발성은 다시 한 번 불필요합니다.

휘발성을 사용하려는 유혹을받는 또 다른 상황은 프로세서가 변수 값을 기다리는 중입니다. 바쁜 대기를 수행하는 올바른 방법은 다음과 같습니다.

while (my_variable != what_i_want)
    cpu_relax();

cpu_relax () 호출은 CPU 전력 소비를 낮추거나 하이퍼 스레드 트윈 프로세서에 대한 수율을 제공합니다. 또한 메모리 장벽 역할을하기 때문에 다시 한번 휘발성이 필요하지 않습니다. 물론, 바쁘게 기다리는 것은 일반적으로 시작하는 반 사회적 행동입니다.

커널에서 휘발성이 의미가있는 몇 가지 드문 상황이 여전히 있습니다.

• 위에서 언급 한 접근 자 함수는 직접 I / O 메모리 액세스가 작동하는 아키텍처에서 휘발성을 사용할 수 있습니다. 기본적으로 각 접근 자 호출은 자체적으로 약간 중요한 부분이되고 프로그래머가 예상 한대로 액세스가 이루어 지도록합니다.

• 메모리를 변경하지만 다른 눈에 띄는 부작용이없는 인라인 어셈블리 코드는 GCC에 의해 삭제 될 위험이 있습니다. volatile 키워드를 asm 문에 추가하면 이러한 제거가 방지됩니다.

• jiffies 변수는 참조 될 때마다 다른 값을 가질 수 있다는 점에서 특별하지만 특별한 잠금없이 읽을 수 있습니다. 따라서 지프는 휘발성이 될 수 있지만이 유형의 다른 변수를 추가하는 것은 매우 어려워집니다. Jiffies는 이와 관련하여 "멍청한 유산"문제 (Linus의 말)로 간주됩니다. 그것을 고치는 것은 가치보다 더 문제가 될 것입니다.

• I / O 장치에 의해 수정 될 수있는 코 히어 런트 메모리의 데이터 구조에 대한 포인터는 때때로 합법적으로 휘발성 일 수 있습니다. 네트워크 어댑터가 사용하는 링 버퍼 (어댑터가 포인터를 변경하여 처리 된 디스크립터를 표시 함)는 이러한 유형의 상황의 예입니다.

대부분의 코드에서 휘발성에 대한 위의 근거 중 어느 것도 적용되지 않습니다. 결과적으로 휘발성의 사용은 버그로 보일 수 있으며 코드를 추가로 조사합니다. 휘발성을 사용하려는 개발자는 한 발짝 물러서서 진정으로 달성하려는 것에 대해 생각해야합니다.

나는 당신이 틀렸다고 생각하지 않습니다-값이 스레드 A 이외의 다른 값으로 변경되면 스레드 A가 값 변경을 볼 수 있도록 휘발성이 필요합니다. volatile은 기본적으로 컴파일러는 "이 변수를 레지스터에 캐시하지 말고 항상 액세스 할 때마다 항상 RAM 메모리에서 변수를 읽고 쓰십시오".

혼란은 많은 것들을 구현하기에 충분하지 않기 때문입니다. 특히 최신 시스템은 여러 수준의 캐싱을 사용하고 최신 멀티 코어 CPU는 런타임에 멋진 최적화를 수행하고 최신 컴파일러는 컴파일 타임에 멋진 최적화를 수행하므로 다양한 부작용이 다르게 나타날 수 있습니다. 소스 코드를 보았을 때 예상 한 순서대로 주문하십시오.

휘발성 변수의 '관측 된'변화가 예상대로 정확하게 발생하지 않을 수 있다는 것을 명심하는 한 휘발성은 좋습니다. 특히 휘발성 변수는 스레드간에 작업을 동기화하거나 순서를 지정하는 방법으로 사용하지 마십시오. 안정적으로 작동하지 않기 때문입니다.

개인적으로 휘발성 플래그에 대한 나의 주요한 사용 (전용?)은 "pleaseGoAwayNow"부울입니다. 계속 반복되는 작업자 스레드가있는 경우 루프의 각 반복에서 휘발성 부울을 확인하고 부울이 참이면 종료합니다. 그런 다음 기본 스레드는 부울을 true로 설정 한 다음 pthread_join ()을 호출하여 작업자 스레드가 없어 질 때까지 대기하여 작업자 스레드를 안전하게 정리할 수 있습니다.

volatilespinlock 뮤텍스의 기본 구성을 구현하는 데 유용하지만 (충분하지는 않지만), 일단 그 (또는 우수한 것)이 있으면 다른 것이 필요하지 않습니다 volatile.

다중 스레드 프로그래밍의 일반적인 방법은 시스템 수준에서 모든 공유 변수를 보호하는 것이 아니라 프로그램 흐름을 안내하는 보호 변수를 도입하는 것입니다. volatile bool my_shared_flag;너 대신에

pthread_mutex_t flag_guard_mutex; // contains something volatile
bool my_shared_flag;

이것은 "하드 파트"를 캡슐화 할뿐만 아니라 기본적으로 필요합니다. C는 뮤텍스를 구현하는 데 필요한 원자 연산을 포함하지 않습니다 . 일반적인 작업 volatile에 대해서만 추가 보증을해야 합니다.

이제 다음과 같은 것이 있습니다.

pthread_mutex_lock( &flag_guard_mutex );
my_local_state = my_shared_flag; // critical section
pthread_mutex_unlock( &flag_guard_mutex );

pthread_mutex_lock( &flag_guard_mutex ); // may alter my_shared_flag
my_shared_flag = ! my_shared_flag; // critical section
pthread_mutex_unlock( &flag_guard_mutex );

my_shared_flag 캐시 할 수없는 상태 임에도 불구하고 일시적 일 필요는 없습니다.

1. 다른 스레드가 액세스 할 수 있습니다.
2. 그것은 그것에 대한 참조가 언젠가 ( &운영자 와 함께) 취해 졌음을 의미합니다 .
   • (또는 함유 구조에 대한 참조가 취해졌습니다)
3. pthread_mutex_lock 라이브러리 함수입니다.
4. 컴파일러가 pthread_mutex_lock어떻게 든 그 참조를 얻었 는지 알 수 없다는 것을 의미합니다 .
5. 컴파일러가 공유 플래그 를 수정 한다고 가정 해야 함을 의미합니다 !pthread_mutex_lock
6. 따라서 변수를 메모리에서 다시로드해야합니다. volatile이 문맥에서 의미가 있지만, 외부 적입니다.

당신의 이해는 실제로 잘못되었습니다.

휘발성 변수가 갖는 속성은 "이 변수에서 읽고 쓰는 것은 프로그램의 인식 가능한 동작의 일부"입니다. 이는이 프로그램이 작동 함을 의미합니다 (제공된 적절한 하드웨어)

int volatile* reg=IO_MAPPED_REGISTER_ADDRESS;
*reg=1; // turn the fuel on
*reg=2; // ignition
*reg=3; // release
int x=*reg; // fire missiles

문제는 이것이 스레드 안전에서 원하는 속성이 아니라는 것입니다.

예를 들어, 스레드 안전 카운터는 다음과 같습니다 (리눅스 커널과 유사한 코드, c ++ 0x에 해당하는 것을 모름).

atomic_t counter;

...
atomic_inc(&counter);

이것은 메모리 장벽이없는 원 자성입니다. 필요한 경우 추가해야합니다. 휘발성을 추가하면 주변 코드에 대한 액세스와 관련이 없기 때문에 도움이되지 않을 것입니다 (예 : 카운터가 계산하는 목록에 요소 추가). 물론, 프로그램 외부에서 카운터가 증가하는 것을 볼 필요는 없으며, 예를 들어 최적화가 여전히 바람직합니다.

atomic_inc(&counter);
atomic_inc(&counter);

여전히 최적화 할 수 있습니다

atomically {
  counter+=2;
}

옵티마이 저가 충분히 똑똑하다면 (코드의 의미를 변경하지 않습니다).

동시 환경에서 데이터가 일관성을 유지하려면 다음 두 가지 조건을 적용해야합니다.

1) 원 자성, 즉 메모리에서 일부 데이터를 읽거나 쓰면 해당 데이터가 한 번에 읽히고 쓰여지며 컨텍스트 스위치로 인해 중단되거나 문제를 일으킬 수 없습니다.

2) 일관성이 있어야합니다 읽기 / 쓰기 작전의 순서를, 즉 본 여러 개의 동시 환경과 동일하게 -하는 것이 스레드, 기계 등

휘발성은 상기 중 어느 것에도 맞지 않으며, 특히 휘발성이 어떻게 작용해야하는지에 관한 c 또는 c ++ 표준은 상기 중 어느 것도 포함하지 않습니다.

인텔 Itanium 컴파일러와 같은 일부 컴파일러는 동시 액세스 안전 동작의 일부 요소 (예 : 메모리 펜스를 보장)를 구현하려고 시도하지만 실제로는 구현이 더 나쁘지만 컴파일러 구현간에 일관성이 없으며 표준에는 이것을 요구하지 않습니다. 우선 구현의.

변수를 휘발성으로 표시하면 기본적으로 캐시 성능이 저하되어 코드가 느려질 때마다 값을 메모리로 플러시하거나 메모리에서 플러시해야합니다.

c # 및 java AFAIK는 1) 및 2)를 휘발성으로 준수 하여이 문제를 해결하지만 c / c ++ 컴파일러에 대해서도 동일하게 말할 수 없으므로 기본적으로 적합하다고 생각하면됩니다.

주제에 좀 더 깊이 (편견 아니지만) 설명은 읽는 이를

comp.programming.threads FAQ는 Dave Butenhof 의 고전적인 설명입니다 .

Q56 : 공유 변수를 VOLATILE로 선언 할 필요가없는 이유는 무엇입니까?

그러나 컴파일러와 스레드 라이브러리가 각각의 사양을 충족시키는 경우에 대해 걱정하고 있습니다. 적합한 C 컴파일러는 일부 공유 (비 휘발성) 변수를 CPU가 스레드에서 스레드로 전달 될 때 저장 및 복원되는 레지스터에 전역 적으로 할당 할 수 있습니다. 각 스레드는이 공유 변수에 대한 자체 값을 가지게되는데 이는 공유 변수에서 원하는 것이 아닙니다.

어떤 의미에서 컴파일러가 변수의 각 범위와 pthread_cond_wait (또는 pthread_mutex_lock) 함수에 대해 충분히 알고 있다면 이것은 사실입니다. 실제로 대부분의 컴파일러는 루틴이 어떻게 든 데이터 주소에 액세스 할 수 있는지 여부를 알기가 어렵 기 때문에 외부 함수 호출을 통해 전역 데이터의 복사본을 유지하려고 시도하지 않습니다.

따라서 ANSI C를 엄격하게 (매우 적극적으로) 준수하는 컴파일러는 휘발성이없는 여러 스레드에서 작동하지 않을 수 있습니다. 그러나 누군가가 더 잘 고쳤습니다. POSIX 메모리 일관성 보장을 제공하지 않는 SYSTEM (즉, 커널, 라이브러리 및 C 컴파일러의 조합)은 POSIX 표준을 따르지 않기 때문입니다. 기간. POSIX는 POSIX 동기화 기능 만 필요하기 때문에 시스템은 올바른 동작을 위해 공유 변수에 휘발성을 사용할 필요가 없습니다.

따라서 휘발성을 사용하지 않아 프로그램이 중단되면 버그입니다. C의 버그, 스레드 라이브러리의 버그 또는 커널의 버그가 아닐 수 있습니다. 그러나 이것은 SYSTEM 버그이며 이러한 구성 요소 중 하나 이상이 문제를 해결해야합니다.

차이를 만드는 시스템에서는 적절한 비 휘발성 변수보다 훨씬 비싸기 때문에 휘발성을 사용하고 싶지 않습니다. (ANSI C는 각 표현식에서 휘발성 변수에 대해 "시퀀스 포인트"가 필요한 반면 POSIX는 동기화 작업에서만 변수를 필요로합니다. 계산 집약적 인 스레드 응용 프로그램은 휘발성을 사용하여 실질적으로 더 많은 메모리 활동을 볼 수 있으며 결국 메모리 활동입니다. 정말 속도가 느려집니다.)

/ --- [Dave Butenhof] ----------------------- [butenhof@zko.dec.com] --- \
| Digital Equipment Corporation 110 스핏 브룩로드 ZKO2-3 / Q18 |
| 603.881.2218, 팩스 603.881.0120 Nashua NH 03062-2698 |
----------------- [동시성을 통한 더 나은 생활] ---------------- /

Butenhof는 이 유즈넷 게시물 에서 동일한 근거를 다룹니다 .

"휘발성"을 사용하는 것은 적절한 메모리 가시성 또는 스레드 간 동기화를 보장하기에 충분하지 않습니다. 뮤텍스의 사용은 충분하며, 이식 불가능한 다양한 머신 코드 대안 (또는 이전 게시물에서 설명한 것처럼 일반적으로 적용하기가 훨씬 어려운 POSIX 메모리 규칙의 미묘한 영향)을 제외하고는 충분하지 않습니다. 뮤텍스는 필수입니다.

따라서 Bryan이 설명했듯이 휘발성을 사용하면 컴파일러가 유용하고 바람직한 최적화를 수행하지 못하도록 방지 할 수 있으며 코드 "스레드 안전"을 만드는 데 도움이되지 않습니다. 물론 원하는 것을 "휘발성"으로 선언 할 수 있습니다. 이는 결국 유효한 ANSI C 스토리지 속성입니다. 스레드 동기화 문제를 해결할 것으로 기대하지 마십시오.

C ++에도 똑같이 적용됩니다.

"불안정한"작업이 전부입니다. "이 컴파일러는 로컬 명령이 실행되지 않더라도이 변수가 모든 시계 틱에서 변경 될 수 있습니다.이 값을 레지스터에 캐시하지 마십시오."

바로 IT입니다. 컴파일러에게 값이 휘발성이라는 것을 알려줍니다.이 값은 외부 로직 (다른 스레드, 다른 프로세스, 커널 등)에 의해 언제든지 변경 될 수 있습니다. 캐시에 본질적으로 안전하지 않은 레지스터의 값을 자동으로 캐시하는 컴파일러 최적화를 억제하는 것은 전적으로 존재합니다.

멀티 스레드 프로그래밍을위한 만병 통치약으로 변덕스러운 "Dr. Dobbs"와 같은 기사가 나타날 수 있습니다. 그의 접근 방식에는 완전히 장점이 없지만 객체 사용자가 스레드 안전을 책임지게하는 근본적인 결함이 있습니다. 이는 다른 캡슐화 위반과 동일한 문제를 일으키는 경향이 있습니다.

저의 오래된 C 표준에 따르면, "유효한 유형을 가진 객체에 대한 액세스를 구성하는 것은 구현 정의되어 있습니다" . 따라서 C 컴파일러 작성자 는 " 다중 프로세스 환경에서 스레드 안전 액세스"를 "휘발성"으로 선택했을 수 있습니다 . 그러나 그들은하지 않았다.

대신, 멀티 코어 멀티 프로세스 공유 메모리 환경에서 중요한 섹션 스레드를 안전하게 만드는 데 필요한 작업이 새로운 구현 정의 기능으로 추가되었습니다. 그리고 "휘발성"이 다중 프로세스 환경에서 원자 적 액세스 및 액세스 순서를 제공해야한다는 요구에서 벗어난 컴파일러 작성자는 과거의 구현 의존적 "휘발성"시맨틱보다 코드 축소를 우선시했습니다.

즉, 새로운 컴파일러가있는 새 하드웨어에서는 작동하지 않는 중요 코드 섹션 주위의 "휘발성"세마포어와 같은 것들이 옛날 하드웨어의 오래된 컴파일러에서는 한 번 작동했을 수도 있고, 오래된 예제는 때때로 오래된 것이 아닙니다.