1. vtkTimeStamp

vtkTimeStamp는 vtk의 가장 근간이 되는 클래스로, 객체의 변경? 업데이트? 여부를 관리하는 클래스

vtk는 수많은 상속구조로 되어 있는데 이 vtkTimeStamp는 아무 것도 상속받지 않은 단독 클래스다.

 

Modified라는 함수 내에서 static으로 atomic<uint64> 형태의 카운팅 변수를 들고 있고, 객체가 업데이트되면 이 정수값을 증가시킨후 객체의 내부 MTime 변수에 대입한다.

이 정수값이 가장 큰 오브젝트가 가장 최근에 업데이트된 객체라는 것을 알아차릴 수 있고, 업데이트 유무도 이 정수값을 통해 확인할 수 있다.

 

ModifiedTime을 통해 내부적으로 변경 여부를 관리한다 (생성자에서 0으로 초기화)

New, Delete는 클래스 단위에서 객체의 생성(new)과 소멸(delete)를 함수형태로 관리하는 것에 지나지 않아 보임

 

TimeStamp 비교 연산자를 오버로딩해서 어느 객체가 더 최근에 업데이트되었는지를 검사한다.

 

객체를 MTimeType으로 변환할 수 있는 변환연산자 제공

 

static 형태로 해당 클래스 공용으로 쓸 수 있는 변수 GlobalTimeStamp를 0U로 초기화한 후,

Modified가 호출될 때마다 이 변수의 값을 증가시켜 멤버변수 ModifiedTime에 대입한다.

 

  // Here because of a static destruction error? You're not the first. After
  // discussion of the tradeoffs, the cost of adding a Schwarz counter on this
  // static to ensure it gets destructed is unlikely to be worth the cost over
  // just leaking it.
  //
  // Solutions and their tradeoffs:
  //
  //  - Schwarz counter: each VTK class now has a static initializer function
  //    that increments an integer. This cannot be inlined or optimized away.
  //    Adds latency to ParaView startup.
  //  - Separate library for this static. This adds another library to VTK
  //    which are already legion. It could not be folded into a kit because
  //    that would bring you back to the same problem you have today.
  //  - Leak a heap allocation for it. It's 24 bytes, leaked exactly once, and
  //    is easily suppressed in Valgrind.
  //
  // The last solution has been decided to have the smallest downside of these.
  //
  // Good luck!
  
  -translate
  // 여기 이 코드가 존재하는 이유는 정적(static) 객체의 소멸 시 발생하는 오류 때문입니다. 
// 당신이 처음 겪는 사람은 아닙니다. 여러 대안들을 논의해 본 결과,
// 이 static 객체가 제대로 소멸되도록 Schwarz 카운터를 도입하는 비용보다,
// 그냥 메모리를 누수(leak)시키는 편이 더 나은 것으로 판단되었습니다.
//
// 가능한 해결책들과 그에 따른 트레이드오프는 다음과 같습니다:
//
//  - Schwarz 카운터: VTK의 각 클래스마다 정적 초기화 함수(static initializer)가 필요해지며, 
//    이 함수는 정수 값을 증가시키는 역할을 합니다. 이는 인라인(inline) 최적화가 불가능하고,
//    ParaView의 시작 속도를 느리게 만듭니다.
//
//  - 이 static 객체만을 위한 별도의 라이브러리를 만드는 방법: 
//    그러나 VTK는 이미 너무 많은 라이브러리를 가지고 있고,
//    이 static이 하나의 kit에 포함된다면 지금과 똑같은 문제가 다시 발생하게 됩니다.
//
//  - 힙 메모리를 한 번만 할당하고 누수시키기(leak): 
//    메모리 크기는 24바이트에 불과하고, 단 한 번만 누수되며,
//    Valgrind에서 쉽게 무시(suppress)될 수 있습니다.
//
// 마지막 방법(누수)이 위 옵션 중에서 가장 부작용이 적은 것으로 결정되었습니다.
//
// 행운을 빕니다!

 

Modified Time을 관리하는 여러 방법 중 지금의 24바이트를 누수시키는 방법은 나머지 선택지 중에 가장 나은 선택이었다는 설명

 

---

hmTimeStamp(vtkTimeStamp)

 

hmTimeStamp.h

 

 

hmTimeStamp.cpp

 

 

 

---

5Q

 

1. 이 클래스의 구현 이유

 - 객체의 업데이트 여부를 관리하고 업데이트가 필요한 객체만 업데이트할 수 있도록 구현하기 위해

 

2. GlobalTimeStamp가 overflow될 가능성은?

 - 이론적으로는 가능하나 현실적으로 일어날 수 없음 (초당 10억번의 Modified가 호출되어도 292년이 걸림)

 

3. 객체의 생성/소멸을 내부 함수 New/Delete로 관리하는 이유

 - New/Delete 함수를 통해 생성/소멸 시점을 추적할 수 있음

 

4. operator >, <는 주로 어디에 쓰이는지

 - 객체간의 정렬, 비교, 우선순위 판단에 쓰임

 - 각 객체는 MTime을 가지고 있기 때문에 이 MTime을 가지고 가장 최근에 업데이트된 객체를 추릴 수 있음

 - 객체 상태 비교에 쓰임 (어느 객체가 더 최근에 수정되었는지)

 

5. 이 클래스로부터 기대할 수 있는 성능적 이점

 - 이후에 등장할 vtkObserver와 결합되어 더 강력한 성능적 이점 부여

 - Observer에서 해당 객체에 대한 업데이트를 진행하려할 때, '정말 변경되었는가'에 대한 답을 줄 수 있음