작성
·
713
1
16바이트 정렬이기 때문에 하위 4비트가 0이라는 답변에 대해서 이해가 안가서 다시 질문을 올렸는데 답변을 해주시지 않으셔서 다시 질문 드립니다.
SListHeader를 16바이트 정렬시 주소가 정말 16의 배수대로 나오는지 확인해봤습니다.
몇번을 다시 해봐도 16의 배수로 나오지 않았습니다.
SListHeader를 그대로 출력해본 결과 아래와 같은 결과가 나왔습니다.
16진수 0x012B8E30 => 10진수 19,631,664 : 16의 배수 맞음
16진수 0x012B47C8 => 10진수 19,613,640 : 16의 배수 아님
16진수 0x012B4808 => 10진수 19613704 : 16의 배수 아님
이렇게 나오는데 어떻게 16의 배수라는 설명을 이해해야하는지 모르겠습니다.
16의 배수로 떨어진다면 16진수의 끝자리는 0으로 끝나기 때문에 bit shift>>4를 해줬다가 다시 <<4 로 복원해줘도 문제가 될게 없다는 말은 이해가 되는데,
16바이트의 배수라는 말이 이해가 안됩니다.
답변 1
4
16진수 0x012B8E30 => 10진수 19,631,664 : 16의 배수 맞음
16진수 0x012B47C8 => 10진수 19,613,640 : 16의 배수 아님
16진수 0x012B4808 => 10진수 19613704 : 16의 배수 아님
사실 잘 이해하셨는데요. 위와 같은 얘기를 하는게 맞습니다.
주소가 16으로 나뉘어야 한다는 것이고,
실험을 x86에서 하신거 같은데 환경 설정을 x64 (64비트 환경)으로 바꾸면,
대부분 최신 버전 컴파일러에서는 주소가 16 배수로 떨어집니다.
만약 특정 환경에서 16으로 떨어지지 않는다면,
aligned_malloc 등 다른 함수를 이용해서 할당하면 됩니다.
그 외 심오한 이야기는 없고
Windows에서 제공해주는 SLIST 등을 사용하기 위한 전제 조건이
무조건! 16바이트 정렬을 해줘야 한다. 그렇지 않으면 어떤 일이 일어날지 모른다! 는 것입니다.
(= 객체 할당했을 때 그 주소가 16으로 나뉘어야 함)
그 이유는 이번 예제에서 실습한대로 bit shift >> 4 등과 유사하게
lockfree 연산 자체에서 전제 조건이 있을 것이라 유추할 수 있는 것이죠.