| 이전 주제 보기 :: 다음 주제 보기 |
| 글쓴이 |
메시지 |
비회원
손님
|
 Interlock 계열의 함수중 비교에 관한건 없는거 같은데요.. |
올려짐: 2009-03-13 01:07
|
|
Interlock 계열 함수들을보면 Write에 관한것은 API가 있는데 read에 관한부분은 없네요
비교 할때는 Interlock 같은 계열함수를 통하지 않고 그냥 비교 해도 되는걸까요? |
|
| 위로 |
|
 |
비회원
손님
|
| |
올려짐: 2009-03-13 03:18
|
|
당연합니다. 수십개 쓰레드가 동시에 read 를 해도 데이타는 망가지지 않기 때문입니다.
그러나 변할만한 변수를 읽었을 때 read 결과로 어떤 값이 들어와 있을 지는 알수 없습니다.
하지만 완전 쌩뚱맞은 값은 아닙니다.
예를들어 다른 쓰레드에서 바꾸는 중인 32bit 정수의 비트 일부분만 바뀌어 있다거나 하지는 않지요. |
|
| 위로 |
|
|
조성경
가입: 2005년 12월 13일
올린 글: 307
|
| |
올려짐: 2009-03-13 08:58
|
|
위의 비회원님께서 말씀하신것처럼 대부분의 경우에 읽기는 안전합니다. 그러나 최적화가 관련되었을때는 재밌는 현상이 발생할 수 있습니다. 컴파일러가 최적화를 위해서 문장의 실행 순서를 바꾸기도 하거든요.
그러니까 다른 쓰레드에서 바꿀 수 있는 값을 조건으로 문장의 실행 순서를 생각하고 프로그램을 작성하면 웃기는 현상이 발생할 수 있습니다. 이런 문제를 해결하기 위해서 volatile같은 예약어를 사용하거나 _Read(Write)Barrier intrinsic같은 것을 사용할 수 있습니다.
그러나 volatile을 쓰는게 삽질이다!!라는 최근의 추세를 적용해 볼 때 쓸곳과 안쓸곳을 정확히 파악하는건 본인의 선택입니다(무책임하죠?)
_________________
더 이상 이 곳에 오지 않습니다. |
|
| 위로 |
|
|
magicpotato
가입: 2003년 9월 29일
올린 글: 21
|
| |
올려짐: 2009-03-13 11:04
|
|
| 조성경 씀: |
| 그러나 volatile을 쓰는게 삽질이다!!라는 최근의 추세를 적용해 볼 때 쓸곳과 안쓸곳을 정확히 파악하는건 본인의 선택입니다(무책임하죠?) |
volatile을 쓰는게 어떤 부분이 삽질인지 궁금합니다. =) |
|
| 위로 |
|
|
조성경
가입: 2005년 12월 13일
올린 글: 307
|
| |
올려짐: 2009-03-13 11:25
|
|
| magicpotato 씀: |
| volatile을 쓰는게 어떤 부분이 삽질인지 궁금합니다. =) |
volatile considered harmful
_________________
더 이상 이 곳에 오지 않습니다. |
|
| 위로 |
|
|
park
가입: 2008년 7월 30일
올린 글: 188
소속: bandi
|
| |
올려짐: 2009-03-13 11:54
|
|
| 비회원 씀: |
예를들어 다른 쓰레드에서 바꾸는 중인 32bit 정수의 비트 일부분만 바뀌어 있다거나 하지는 않지요. |
이부분은 평소에 궁금하던 사항인데, 하드웨어에서 보장이 되는 사항인가요? (특히 멀티코어에서)
혹시 보장이 된다면, 32비트가 아닌 64비트 정수에 대해서도 보장이 될까요?
혹시 알고 계시는분 답변 부탁드립니다. |
|
| 위로 |
|
|
비회원
손님
|
| |
올려짐: 2009-03-13 17:25
|
|
http://www.aristeia...Aug_2004_revised.pdf
volatile이 등장하게 된 배경에 대한 설명이 있으니 참고 하시구요..
위와 같은 경우에는 memory barrier가 필요한 상황인데 C/C++의 volatile은 그것을 지원하지 못하는데 문제가 있습니다.
다시말해 C/C++의 volatile은 read/write operation에 대해서 최적화를 하지 않는 것이고 .NET이나 Java의 volatile은 C/C++의 volatile에 reordering까지 방지하는 volatile입니다. |
|
| 위로 |
|
|
magicpotato
가입: 2003년 9월 29일
올린 글: 21
|
| |
올려짐: 2009-03-13 19:04
|
|
그냥 지나치고 오래전 지식으로 코딩했으면 큰일날뻔 한 부분이네요..
위에 두분 답변 감사합니다 =)
참고로 영어는 읽기 귀찮아서 다시 검색했는데 http://skyul.tistory.com/337 이게 보기 편하네요 |
|
| 위로 |
|
|
비회원
손님
|
| |
올려짐: 2009-03-14 12:09
|
|
| park 씀: |
| 비회원 씀: |
예를들어 다른 쓰레드에서 바꾸는 중인 32bit 정수의 비트 일부분만 바뀌어 있다거나 하지는 않지요. |
이부분은 평소에 궁금하던 사항인데, 하드웨어에서 보장이 되는 사항인가요? (특히 멀티코어에서)
혹시 보장이 된다면, 32비트가 아닌 64비트 정수에 대해서도 보장이 될까요?
혹시 알고 계시는분 답변 부탁드립니다. |
Intel? 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide 의
7.1.1 Guaranteed Atomic Operations 부분에서 보실 수 있습니다.  |
|
| 위로 |
|
|
park
가입: 2008년 7월 30일
올린 글: 188
소속: bandi
|
| |
올려짐: 2009-03-14 21:44
|
|
| 비회원 씀: |
| park 씀: |
| 비회원 씀: |
예를들어 다른 쓰레드에서 바꾸는 중인 32bit 정수의 비트 일부분만 바뀌어 있다거나 하지는 않지요. |
이부분은 평소에 궁금하던 사항인데, 하드웨어에서 보장이 되는 사항인가요? (특히 멀티코어에서)
혹시 보장이 된다면, 32비트가 아닌 64비트 정수에 대해서도 보장이 될까요?
혹시 알고 계시는분 답변 부탁드립니다. |
Intel? 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide 의
7.1.1 Guaranteed Atomic Operations 부분에서 보실 수 있습니다. |
감사합니다. 궁금증이 풀렸네요. 혹시 궁금해서 찾아보실 분들을 위해서..
7.1.1. Guaranteed Atomic Operations
The Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors guarantee that the
following basic memory operations will always be carried out atomically:
• Reading or writing a byte.
• Reading or writing a word aligned on a 16-bit boundary.
• Reading or writing a doubleword aligned on a 32-bit boundary.
The Pentium 4, Intel Xeon, and P6 family, and Pentium processors guarantee that the following
additional memory operations will always be carried out atomically:
• Reading or writing a quadword aligned on a 64-bit boundary.
• 16-bit accesses to uncached memory locations that fit within a 32-bit data bus.
The P6 family processors guarantee that the following additional memory operation will always
be carried out atomically:
• Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a 32-byte cache
line.
Accesses to cacheable memory that are split across bus widths, cache lines, and page boundaries
are not guaranteed to be atomic by the Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486
processors. The Pentium 4, Intel Xeon, and P6 family processors provide bus control signals that
permit external memory subsystems to make split accesses atomic; however, nonaligned data
accesses will seriously impact the performance of the processor and should be avoided. |
|
| 위로 |
|
|
Testors
가입: 2003년 7월 26일
올린 글: 557
소속: (주)nFlavor
타 사이트 ID(?):
48179650
|
| |
올려짐: 2009-03-16 11:08
|
|
링크해 주신 글에 이런 내용이 있는데요, 좀 이해가 안가서 덧붙입니다.
| 인용: |
58 Another situation where one might be tempted to use volatile is
59 when the processor is busy-waiting on the value of a variable. The right
60 way to perform a busy wait is:
61
62 while (my_variable != what_i_want)
63 cpu_relax();
64
65 The cpu_relax() call can lower CPU power consumption or yield to a
66 hyperthreaded twin processor; it also happens to serve as a memory barrier,
67 so, once again, volatile is unnecessary. |
이건 memory barrier 와는 상관이 없는 내용인것 같아 보이는데요... 컴파일러가 my_variable 을 레지스터로 최적화 시켜버리면 영원히 cpu_relax() 만 불릴것 같습니다. 제가 볼때는 이건 꼭 volatile 을 써야만 하는 부분으로 보이는데... 왜 volatile 이 불필요하다고 주장하고 있는지 이해하기 힘들군요. 실제로도 테스트를 해 보았는데 volatile 이 없으면 문제가 발생했습니다.
_________________
플머/모델러/애니메이터 구해염 **현역/보충역 병특가능** / http://testors.net/ |
|
| 위로 |
|
|
조성경
가입: 2005년 12월 13일
올린 글: 307
|
| |
올려짐: 2009-03-17 14:44
|
|
| Testors 씀: |
링크해 주신 글에 이런 내용이 있는데요, 좀 이해가 안가서 덧붙입니다.
| 인용: |
58 Another situation where one might be tempted to use volatile is
59 when the processor is busy-waiting on the value of a variable. The right
60 way to perform a busy wait is:
61
62 while (my_variable != what_i_want)
63 cpu_relax();
64
65 The cpu_relax() call can lower CPU power consumption or yield to a
66 hyperthreaded twin processor; it also happens to serve as a memory barrier,
67 so, once again, volatile is unnecessary. |
이건 memory barrier 와는 상관이 없는 내용인것 같아 보이는데요... 컴파일러가 my_variable 을 레지스터로 최적화 시켜버리면 영원히 cpu_relax() 만 불릴것 같습니다. 제가 볼때는 이건 꼭 volatile 을 써야만 하는 부분으로 보이는데... 왜 volatile 이 불필요하다고 주장하고 있는지 이해하기 힘들군요. 실제로도 테스트를 해 보았는데 volatile 이 없으면 문제가 발생했습니다. |
저는 이 글을 볼때 cpu_relax가 memory barrier 역할을 해주는 함수라고 이해했습니다(문장 자체가 그렇죠). 리눅스쪽에 있는 함수는 그렇구만하고 이해를 한거죠.
그리고 my_variable이 자동변수가 아니라면 레지스터로 최적화되는 일은 없을거라 판단이 됩니다. 실제 테스트해보신 코드가 궁금하네요. cpu_relex 함수는 아니지만 아래처럼 CCAS 구현하는 경우가 문제가 된적도 없구요. InterlockedExchange가 memory barrier역할을 하는 점을 빼면 위의 예와 크게 다르지 않다고 생각합니다.
| 코드: |
for (;;)
{
if (value == 0 && InterlockedExchange(&value, 1) == 0)
break;
Sleep(0);
}
|
추가:
글을 쓰고 다시 읽어보니 CAS라고 쓰고 InterlockedExchange를 사용해서 코드를 써놨군요. InterlockedCompareExchange와 같은 결과가 나오니 그런가보다하고 봐주세요.
_________________
더 이상 이 곳에 오지 않습니다.
조성경 가 2009-03-17 14:58에 수정함, 총 1 번 수정됨 |
|
| 위로 |
|
|
조성경
가입: 2005년 12월 13일
올린 글: 307
|
| |
올려짐: 2009-03-17 14:53
|
|
| 비회원 씀: |
위와 같은 경우에는 memory barrier가 필요한 상황인데 C/C++의 volatile은 그것을 지원하지 못하는데 문제가 있습니다.
다시말해 C/C++의 volatile은 read/write operation에 대해서 최적화를 하지 않는 것이고 .NET이나 Java의 volatile은 C/C++의 volatile에 reordering까지 방지하는 volatile입니다. |
제품별로 다른 내용입니다. C++라서 안되는게 아니라 제품 사양을 보고 결정할 내용입니다.
_________________
더 이상 이 곳에 오지 않습니다. |
|
| 위로 |
|
|
조성경
가입: 2005년 12월 13일
올린 글: 307
|
| |
올려짐: 2009-03-17 22:34
|
|
| 비회원 씀: |
"InterlockedExchange가 memory barrier역할을 하는 점"
=> 인터락 함수와 memory barrier는 전혀 관계가 없습니다 (제가 알기로). Interlocked* 계열은 결국 x86 명령어에 LOCK 접두어를 붙이는 겁니다. Memory barrier는 mfence/sfence/lfence로 따로 존재하는 전혀 다른 종류의 명령입니다. 메모리 배리어가 있으면 프로세서 파이프라인을 지금 pending 된 모든 명령들이 완료될때까지 중단시킵니다. |
Interlocked* 함수들의 선언을 보면 LONG volatile* target처럼 volatile이 붙어 있습니다. 명령에 붙은 LOCK 때문이 아니라 저 volatile 때문에 memory barrier 역할을 하게되죠. volatile을 기준으로 캐쉬라인을 정리하니까요.
제가 쓴 memory barrier라는 단어는 _Read(Write)Barrier와 동의어라고 보셔도 됩니다. memory barrier가 말씀하신 mfence/sfence/lfence만을 의미한다면 제가 단어 사용을 잘못했네요.
추가:
쓰고 보니 이상하네요. CPU에 분명히 memory barrier 명령어가 있겠지만 - 그게 말씀하신 *fence 명령어겠죠 - _Read(Write)Barrier intrinsic과 다른 명령어라고 생각되지 않습니다.
_________________
더 이상 이 곳에 오지 않습니다. |
|
| 위로 |
|
|
Testors
가입: 2003년 7월 26일
올린 글: 557
소속: (주)nFlavor
타 사이트 ID(?):
48179650
|
| |
올려짐: 2009-03-18 01:06
|
|
| 조성경 씀: |
| 그리고 my_variable이 자동변수가 아니라면 레지스터로 최적화되는 일은 없을거라 판단이 됩니다. 실제 테스트해보신 코드가 궁금하네요. |
자동변수로 테스트 했습니다.
| 조성경 씀: |
| Interlocked* 함수들의 선언을 보면 LONG volatile* target처럼 volatile이 붙어 있습니다. 명령에 붙은 LOCK 때문이 아니라 저 volatile 때문에 memory barrier 역할을 하게되죠. volatile을 기준으로 캐쉬라인을 정리하니까요. |
그런 의미였다면 "volatile 은 삽질이다" 라는 주장의 근거가 될 수 없습니다. 왜냐하면 결국 문제는 volatile 에 의해 해결된 것이고 다른말로 volatile 이 꼭 필요하다는 의미이기 때문입니다. 저라면 저런 경우에 volatile 을 꼭 명시해 둡니다.
memory barrier 가 자꾸 언급되는데 저는 busy wait 에서의 volatile 과 memory barrier 가 어떤 관계가 있는지 잘 모르겠습니다. (비회원님의 견해와 동일합니다.) 그리고 인용하신 글에 사용된 busy wait 코드는 test and set 을 의미한 것으로 보이지 않습니다.
제 견해는 이렇습니다.
1. volatile considered harmful 의 저자가 뭔가를 오해하고 있다.
2. 혹은 리눅스 커널 개발 환경은 우리가 알고 있는 일반적인 개발 환경과 그 동작에 차이가 있다. (가령 gcc 의 volatile 처리가 특이하다던지...)
여튼 "volatile 은 삽질이다." 라는 주장은 좀 성급한것이 아닌가 싶습니다.
_________________
플머/모델러/애니메이터 구해염 **현역/보충역 병특가능** / http://testors.net/ |
|
| 위로 |
|
|
조성경
가입: 2005년 12월 13일
올린 글: 307
|
| |
올려짐: 2009-03-18 09:27
|
|
글을 쓰고 나서 밤에 공부를 좀 했는데 volatile에 memory barrier에 관련된 부분은 확실히 제가 잘 못 알고 있었습니다. 위에서 제가 volatile과 memory barrier의 관계에 대해서 얘기한건 잘못된 얘기입니다.
나머지 부분들은 정리 좀 해서 다시 글을 올리겠습니다.
_________________
더 이상 이 곳에 오지 않습니다. |
|
| 위로 |
|
|
비회원
손님
|
| |
올려짐: 2009-03-19 12:13
|
|
멀티쓰레드 환경에서 volatile을 사용하는게 삽질이라면 대안이 따로 있나요?
그리고 문뜩 궁금해서 그런데
while (my_variable != what_i_want) cpu_relax();
여기서
my_variable 가 volatile 이 아니라면
한세월 지나 언젠가 cpu 캐쉬라인이 무효화되면 빠져나올수 있지 않을까란 생각이 드는데 맞는지 모르겠네요.. |
|
| 위로 |
|
|
비회원
손님
|
| |
올려짐: 2009-03-19 12:16
|
|
| 비회원 씀: |
멀티쓰레드 환경에서 volatile을 사용하는게 삽질이라면 대안이 따로 있나요?
그리고 문뜩 궁금해서 그런데
while (my_variable != what_i_want) cpu_relax();
여기서
my_variable 가 volatile 이 아니라면
한세월 지나 언젠가 cpu 캐쉬라인이 무효화되면 빠져나올수 있지 않을까란 생각이 드는데 맞는지 모르겠네요.. |
생각해보니 volatile이 아니라면 레지스터값이 스택에 푸시팝되면서 영원이 못나올것 같군요.. |
|
| 위로 |
|
|
비회원
손님
|
| |
올려짐: 2009-03-19 13:27
|
|
__int64 a = 1;
__int64 b = 2;
if(a == b)
printf("haha");
__int64 a = 1;
00401FC8 mov dword ptr [a],1
00401FCF mov dword ptr [ebp-4],0
__int64 b = 2;
00401FD6 mov dword ptr [b],2
00401FDD mov dword ptr [ebp-0Ch],0
if(a == b)
00401FE4 mov eax,dword ptr [a]
00401FE7 cmp eax,dword ptr [b]
00401FEA jne wmain+5Bh (40200Bh)
00401FEC mov ecx,dword ptr [ebp-4]
00401FEF cmp ecx,dword ptr [ebp-0Ch]
00401FF2 jne wmain+5Bh (40200Bh)
printf("haha");
00401FF4 mov esi,esp
00401FF6 push offset ___xi_z+1A8h (4188CCh)
00401FFB call dword ptr [__imp__printf (421604h)]
00402001 add esp,4
00402004 cmp esi,esp
00402006 call _RTC_CheckEsp (40EFB0h)
int a = 1;
int b = 2;
if(a == b)
printf("haha");
int a = 1;
00401FC5 mov dword ptr [a],1
int b = 2;
00401FCC mov dword ptr [b],2
if(a == b)
00401FD3 mov eax,dword ptr [a]
00401FD6 cmp eax,dword ptr [b]
00401FD9 jne wmain+42h (401FF2h)
printf("haha");
00401FDB mov esi,esp
00401FDD push offset ___xi_z+1A8h (4188CCh)
00401FE2 call dword ptr [__imp__printf (421604h)]
00401FE8 add esp,4
00401FEB cmp esi,esp
00401FED call _RTC_CheckEsp (40EFB0h)
x86에서 int와 __int64를 가지고 비교를 수행하는 코드입니다.
__int64의 경우 비교할 때 상위4비트와 하위4비르를 나눠서 수행하네요.
x86에서 __int64 비교할 때는
InterlockedexchangeAdd64(&a, 0) == InterlockedexchangeAdd64(&b, 0)
이런식으로 해야 되지 않을까요? |
|
| 위로 |
|
|
비회원
손님
|
| |
올려짐: 2009-03-21 20:27
|
|
| 보통 32비트 머신(혹은 32비트 호환 모드)에서는 64비트 변수들은 읽기도 원자성이 보장 안 되지 않나요? 예전에 위에 비회원님이 올린 어셈블리 코드와 비슷한 상황 때문에 잠깐 골 때렸던 기억이 있었는데... 혹시 잘못 알고 있던거라면 지적바랍니다. |
|
| 위로 |
|
|
|
FAQ
검색
멤버리스트
사용자 그룹
이미지 자료실
사용자 등록하기
개인 정보
쪽지(개인 메시지)를 확인하려면 로그인하십시오
로그인
[?]
