*volatile이 아니라 그냥 volatile이겠죠.
붙이면 최적화 대상에서 빠집니다.
최적화는 해당 변수의 사용에 대해 어떤 식으로 쓰일거라는 가정을 바탕으로 하는데(라고 알고만 있다는;;;)
어떠한 가정도 하지 않도록 한다지요.
대부분 volatile을 써서 최적화를 못하게 하는 경우는
해당 변수에 할당된 메모리에 어떤 값이 있을때 그걸 최적화하면 캐시를 사용할 수 있는데,
최신의 값이 캐시에만 있고 메모리에 아직 반영이 안된 상태에서
다른 쓰레드가 접근하면 최신의 값을 "못 보는" 현상이 생길 수 있기 때문입니다.
동기화를 해서 피할 수도 있긴 하지만... 모든 변수를 일일이 그렇게 하기 곤란한 경우도 종종 있습니다.
저 같은 경우는 word size로만, 그리고 한 쓰레드만 write하고 다른 쓰레드는 read만 하는 변수에 한해서
동기화를 하지 않고 volatile을 쓰고 있습니다.
또는 해당 프로그램 외적인 외부 요인에 의해서 특정 메모리 번지의 값이 바뀔 경우 (시스템 시간 등)
그 값을 읽어올 수 있도록 하기 위해서 그렇게 하기도 합니다.
역시 최적화에 의해서 캐시를 쓴다면, 백날 가봐야 캐시의 변함없는 값만 읽어대겠죠.
volatile에 의한 코드에 끼쳐지는 영향이 side-effect에 가깝다는 문구를 본 기억이납니다...
멀티프로세서 환경에서는 일반적(?)으로 알려진 volatile의 기능도...
제대로 실행되지 않는 경우가 발생한다고 합니다...
다시 말해서 최적화 외에 캐쉬와 관련된 부분은 실제로.. 일부 환경에서만..
의도적으로 사용할 수 있습니다..
volatile은 해당 변수를 사용할 때,
섣부른 최적화를 자제하고 최대한 원래의 의미 그대로 해석하라는 경고의 의미를 담고 있습니다.
프로그래머가 컴파일러에게 주는 도움말 혹은 안전표지판 같은 거죠.
C 컴파일러는 종종 과격한 최적화가 가능합니다.
같은 블럭 내에서 한 변수가 읽기로만 여러번 쓰일때, 한번만 읽고 CPU 캐쉬에 올려둔 뒤
새로 메모리에서 그 값을 다시 읽어오지 않고 캐쉬의 데이터를 여러번 참조하는 수가 있습니다.
근데 만약 그 사이에 그 변수가 외부적인 요인(예를 들면 memory-mapped IO)에 의해 변경될 수가 있다면,
이런 방식으로 최적화를 해서는 안되겠지요.
혹은, 다음과 같이 같은 변수에 같은 값을 두번 연속으로 쓰는 경우
portA = 0xFF;
portA = 0xFF;
둘중 하나는 무의미한 코드라 생각해서 제거될 수 있습니다.
근데 꼭 두번 쓰여져야 하는 경우가 하드웨어 쪽에서는 가끔 발생하죠.
그럴때 프로그래머는 volatile을 붙여서 컴파일러에게 경고를 해주는 겁니다.
그러나, 그 경고를 어떻게 해석하고 처리할지는 컴파일러 마음이라는거~
그렇다고 최적화를 절대적으로 금지하지는 않습니다.
상당히 헐렁한 의미를 담고 있는 키워드 되겠습니다.
게다가 이 키워드가 동작의 원자성을 보장해주는 것은 아니라서
멀티 쓰레드 환경에서 이 키워드를 믿는것은 대단히 위험합니다.
원래 멀티 쓰레드 환경에서 쓰라고 만든 키워드도 아니고...
동작의 원자성을 보장해주는 것은 아니라는 점은 중요한 말씀입니다.
저의 경우 더도 덜도 아닌 딱 word size의 변수에만 volatile을 사용하는 이유가 바로 그래서입니다.
음... 위의 댓글을 보니 멀티코어 환경에서는 그래도 문제가 생기는지도 모르겠지만
여하튼 제 경험으론 여태까지의 환경에서는 두가지 조건이 만족되면 문제는 없었던 것 같네요.
그래도 가급적 쓰레드간에 공유하는 목적으로는 안 쓰는게 좋겠지요...
*volatile?
*volatile이 아니라 그냥 volatile이겠죠.
붙이면 최적화 대상에서 빠집니다.
최적화는 해당 변수의 사용에 대해 어떤 식으로 쓰일거라는 가정을 바탕으로 하는데(라고 알고만 있다는;;;)
어떠한 가정도 하지 않도록 한다지요.
대부분 volatile을 써서 최적화를 못하게 하는 경우는
해당 변수에 할당된 메모리에 어떤 값이 있을때 그걸 최적화하면 캐시를 사용할 수 있는데,
최신의 값이 캐시에만 있고 메모리에 아직 반영이 안된 상태에서
다른 쓰레드가 접근하면 최신의 값을 "못 보는" 현상이 생길 수 있기 때문입니다.
동기화를 해서 피할 수도 있긴 하지만... 모든 변수를 일일이 그렇게 하기 곤란한 경우도 종종 있습니다.
저 같은 경우는 word size로만, 그리고 한 쓰레드만 write하고 다른 쓰레드는 read만 하는 변수에 한해서
동기화를 하지 않고 volatile을 쓰고 있습니다.
또는 해당 프로그램 외적인 외부 요인에 의해서 특정 메모리 번지의 값이 바뀔 경우 (시스템 시간 등)
그 값을 읽어올 수 있도록 하기 위해서 그렇게 하기도 합니다.
역시 최적화에 의해서 캐시를 쓴다면, 백날 가봐야 캐시의 변함없는 값만 읽어대겠죠.
예외가 있을듯 합니다..
volatile에 의한 코드에 끼쳐지는 영향이 side-effect에 가깝다는 문구를 본 기억이납니다...
멀티프로세서 환경에서는 일반적(?)으로 알려진 volatile의 기능도...
제대로 실행되지 않는 경우가 발생한다고 합니다...
다시 말해서 최적화 외에 캐쉬와 관련된 부분은 실제로.. 일부 환경에서만..
의도적으로 사용할 수 있습니다..
volatile은 해당 변수를
volatile은 해당 변수를 사용할 때,
섣부른 최적화를 자제하고 최대한 원래의 의미 그대로 해석하라는 경고의 의미를 담고 있습니다.
프로그래머가 컴파일러에게 주는 도움말 혹은 안전표지판 같은 거죠.
C 컴파일러는 종종 과격한 최적화가 가능합니다.
같은 블럭 내에서 한 변수가 읽기로만 여러번 쓰일때, 한번만 읽고 CPU 캐쉬에 올려둔 뒤
새로 메모리에서 그 값을 다시 읽어오지 않고 캐쉬의 데이터를 여러번 참조하는 수가 있습니다.
근데 만약 그 사이에 그 변수가 외부적인 요인(예를 들면 memory-mapped IO)에 의해 변경될 수가 있다면,
이런 방식으로 최적화를 해서는 안되겠지요.
혹은, 다음과 같이 같은 변수에 같은 값을 두번 연속으로 쓰는 경우
portA = 0xFF;
portA = 0xFF;
둘중 하나는 무의미한 코드라 생각해서 제거될 수 있습니다.
근데 꼭 두번 쓰여져야 하는 경우가 하드웨어 쪽에서는 가끔 발생하죠.
그럴때 프로그래머는 volatile을 붙여서 컴파일러에게 경고를 해주는 겁니다.
그러나, 그 경고를 어떻게 해석하고 처리할지는 컴파일러 마음이라는거~
그렇다고 최적화를 절대적으로 금지하지는 않습니다.
상당히 헐렁한 의미를 담고 있는 키워드 되겠습니다.
게다가 이 키워드가 동작의 원자성을 보장해주는 것은 아니라서
멀티 쓰레드 환경에서 이 키워드를 믿는것은 대단히 위험합니다.
원래 멀티 쓰레드 환경에서 쓰라고 만든 키워드도 아니고...
> 같은 블럭 내에서
> 같은 블럭 내에서 한 변수가 읽기로만 여러번 쓰일때, 한번만 읽고 CPU 캐쉬에 올려둔 뒤
CPU 캐쉬가 아니라 레지스터겠군요 ㅋ 써놓고 보니 이상해서 정정합니다.
그렇지요.
동작의 원자성을 보장해주는 것은 아니라는 점은 중요한 말씀입니다.
저의 경우 더도 덜도 아닌 딱 word size의 변수에만 volatile을 사용하는 이유가 바로 그래서입니다.
음... 위의 댓글을 보니 멀티코어 환경에서는 그래도 문제가 생기는지도 모르겠지만
여하튼 제 경험으론 여태까지의 환경에서는 두가지 조건이 만족되면 문제는 없었던 것 같네요.
그래도 가급적 쓰레드간에 공유하는 목적으로는 안 쓰는게 좋겠지요...
http://kldp.org/node/84286 v
http://kldp.org/node/84286
volatile 의 경우와는 약간 다르지만.
OTL
volatile
하나의 변수를 2개 이상의 쓰레드에서 공유하는 상황을 생각해 보시면 될 것 같습니다.
첫번째 쓰레드에서 변수 a 의 내용을 갖고와서 레지스터에 넣고..
루프등을 돌면서 사용중인데...
두번째 쓰레드에서 변수 a 의 내용을 수정할 경우 첫번째 쓰레드에선 레지스터에 들어 있는 예전의 값을 그대로 사용하고 있겠죠.
volatile 은 변수 a의 내용을 최적화 대상에서 제외시켜 변수 a를 사용할땐 항상 메모리에서 다시 변수 a 의 내용을 참조하도록 하는 역할을 합니다.
Thanks your advise~~~ Thank
Thanks your advise~~~
Thank you very much!!!
(Now, I can't input Korean~~~ sorry
In fact my English is very poor~~)
좋은 하루 되세요!!
댓글 달기