void* data;

  Field( short lowindex, short highindex )
  {
   _TypeValue.lowindex = lowindex ;
   _TypeValue.highindex = highindex ;
  }
  Field( void *ptr )
  {
   data = ptr;
  }

  void SetIndex( short lowindex, short highindex )
  {
   _TypeValue.lowindex = lowindex;
   _TypeValue.highindex = highindex;
  }
  void SetPointer( void *ptr )
  {
   data = ptr;
  }
  short GetLowIndex()
  {
   return _TypeValue.lowindex;
  }
  short GetHighIndex()
  {
   return _TypeValue.highindex;
  }
  void* GetPointer()
  {
   return data;
  }
 };

동적 스레드 로컬 저장소

스레드마다 할당하는 방식으로 데이터를 저장할 필요가 있거나
이렇게 하는 방법이 더 편할때가 있다.

TlsAllock함수를 사용해서 Index를 할당한다

TlsAllock은 비트 플래그의 배열에서 사용되지 않은 항목을 찾아서 사용하는것으로 표시하고 함수를 호출한 스레드에게 인덱스를 리턴한다.

DWORD TlsAllock(void)

리턴된 Index값을 이용해서 TlsSetValue 함수를 호출하면 인덱스의 위치에 있는
스레드 저장소에 32비트 값을 저장할 수 있다.

BOOL TlsSetValue( DWORD dwTlsIndex, LPVOID lpvTlsValue )

Tls 배열에 저장된 값은 TlsGetValue 함수를 통해서 접근할 수 있다.

LPVOID TlsGetValue( DWORD dwTlsIndex )

TlsAlloc에서 리턴된 Index는 전역 변수에 저장되어
콜 스택을 통하지 않고도 모든 스레드에서 사용할 수 있다.

프로세스가 Tls Index의 사용을 끝나면 TlsFree호출을 이용해서 인덱스를 반환할 수 있다.

BOOL TlsFree( DWORD dwTlsIndex )

정적 스레드 로컬 저장소

정적 스레드 로컬 저장소는 특별한 저장소 선언 지정자 __declspen(thread)를 사용한다.

이 지정자를 사용해서 변수를 정의하면 비쥬얼C++컴파일러가 변수를 .tls라는 이름을 갖는
바이너리 파일의 데이터 영역에 변수를 넣도록 지시한다.

링커는 오브젝트 파일에 있는 모든 .tls파일을 묶어서 EXE나 DLL바이너리 안의 .tls영역에 위치시킨다.

운영체제가 바이너리 실행파일이나 DLL을 로드할때 .tls영역에 대해서 특별한 처리를 한다.
운영체제는 주 스레드의 영역에 있는 모든 변수를 담을 수 있을만한 크기를
별도의 메모리에 할당한다.
새로운 스레드가 프로세스 안에서 할당될 때마다 운영체제는 새로운 스레드를 위한
또 다른 데이터 블록을 할당한다. 특별하게 컴파일러가 생성한 명령어들은
각각의 스레드가 자신을 위해서 특별하게 할당된 데이터 블럭만을 접근하도록 보장한다.

정적 TLS의 문제점은 프로그램이 처음 로드될 때 운영체제가
특별한 .tls 메모리 블럭의 크기를 결정해야 한다는 사실이다.
이것은 EXE파일에 정의된 정적 TLS변수와
제한적으로 링크된 DLL의 경우에도 잘 동작하게 된다. 그러니
LoadLibrary를 사용해서 프로그램 코드가 로드한 DLL은
.tls 메모리 블록의 요구되는 크기를 알수 없으며 처음에 생성할 때
 이외에는 운영체제가 TLS영역의 크기를 확장할 수 없다.
운영체제는 LoadLibrary를 사용해서 .tls 세그먼트를 포함하는
DLL을 로드하도록 하지만, 아마 적절하게 저장소를 할당하지는 못할 것이다.
이런 식으로 로드된 DLL에 정의된 __declspec(thread)변수들을
사용하는는 것은 접근 위반이나 다른 잘못된 결과를 유발할 수 있다.
라이브러리의 정적 스레드 로컬 저장소를 사용할 때 라이브러리가
동적으로 로드되고 링크된다면 아마도 이 라이브러리는 제대로 동작하지 않을 것이다.
따라서 에플리케이션에만 정적 스레드 로컬 저장소를 사용해야 하고,
라이브러리는 동적 스레드 로컬 저장소 API를 사용해야만 한다.


출처 : Win32 Multithreaded Programming

정신차리자!!

덩치가 큰 구조체나 객체의 복사에 따른 성능 감소를 피하기 위해서는

객체 자체가 아니라 객체에 대한 포인터를 넘겨주도록 해야 할 것이다.

동적으로 할당된 구조체나 객체들에 대한 포인터를 다룰 때에는 주의해야 할 점들이 있는데,

객체를 사용하고 난 다음에는 반드시 할당된 메모리를

명시적으로 해제해 주어야 한다는 점이다.

컨테이너 자체는 자신의 가지고 있는 데이터가 어떤것인지를 알지 못하므로

객체들에 할당된 메모리를 컨테이너가 자동적으로 해제하지는 않는다는 점을 명심해야한다.

ex)
for(  std::list< data* >::iterator iter = list.begin(); iter != list.end() ; )
{
    if( (*iter)->GetData() == 2 )
    {
        delete (*iter);
        iter = list.erase(iter);
    }
    else
    {
        iter++;
    }
}


덤으로 위처럼 지운다면 erase의 return값이

다음 iterator를 가르키기때문에 한번의 루프안에 원하는값을

모두 지워줄수있다. ( 난 여태까지 루프 여러번돌렸다 - - )



추가---------------------------------------------------------------------------------

주의할점
포인터가 객체일경우 sort를 했을때 적절한 연산자가 설계되어있다 해도

객체 안의 내용의 정렬되는것이 아닌

포인터의 실제값(즉 메모리 주소)에 대해서 정렬을 수행하는것이다.


주의할점2
컨테이너를 복사할때 복사되는 것은 객체 자체가 아니라 포인터들임을 명심해야 한다.

동일한 객체를 가리키는 포인터가 여러 개 존재한다는 것은

메모리 관리의 측면에서 매우 위험한 일이다.

(한쪽을 해제하면 다른 쪽은 유효하지 않은 메모리를 가리키게 된다).

이에 대한 해결책은 두 가지 뿐이다. 포인터 관리에 세심한 주의를 기울이거나,

컨테이너에서 컨테이너로 요소를 복사하는
 
STL함수나 알고리즘을 사용하지 않는 것이다.


출처 : GameProgramming Gems 1