질문 님이 쓰신 글 :
: 저는 쓰레드 동기화로 TMonitor::Enter와 TMonitor::Exit를 쓰고있는데요
: scoped lock은 다른가요?
:
:
: 빌더(TWx) 님이 쓰신 글 :
: : 음 님이 쓰신 글 :
: : : 2차원 배열 동적할당을 하고
: : : 동적할당된 배열의 사이즈를 찾아보았습니다.
: : :
: : : 1x1 배열을 만든 경우는
: : : 동적할당된 배열의 사이즈는 3x1로 나왔습니다.
: : :
: : : 12x1 배열을 만든 경우는
: : : 동적할당된 배열의 사이즈는 13x1이 나왔습니다.
: : :
: : : 비쥬얼스튜디오에서 한 경우에는 정상적으로 나왔는데 c++ 빌더 커뮤니티 에디션으로 한 결과는 같은 코드에서 이상하게 나왔습니다.
: : : 어디에 문제가 있을까요?
: : :
: : : 아니면 다른 방법이 있다면 추천 부탁드립니다.
: : : 
: : :
: : : 아래는 제가 만든 코드입니다.
: : :
: : : - 2차원 배열 동적 할당   
: : :         double** data;
: : :     //2차원 배열 동적 할당
: : :     data = new double*[m_Rows];
: : :     for(int i = 0; i< m_Rows; i++){
: : :         data[i] = new double[m_Cols];
: : :         for(int j = 0; j<m_Cols; j++){
: : :             data[i][j] = 0;
: : :         }
: : :     }
: : :
: : : - 동적할당된 배열의 사이즈 찾기
: : :     m_Rows = _msize(data)/sizeof(data[0]);
: : :     m_Cols = _msize(data[0])/sizeof(data[0][0]);
: : :
: :
: :
: :
: :
: : 답변:
: :
: :
: : 바빠서 요점만 남깁니다.
: :
: :
: : 델파이 버전 몇 부터인가 부터...
: : 메모리 매니지먼트 코드로 fastMM 을 베겨서 쓰고 있는데
: :
: : fastMM은 힙 블럭을 small, medium, large로 구분해서 메모리를 관리하는
: : 간단한 방법으로 구현되어 있고, 파스칼 컴파일러 자체가 옵티마이징이 후져서
: : 속도를 낸답시고 단무지 같은 방법으로 어셈블리 코드를 잔뜩 쓰고 있죠. (델파이 RTL도 마찬가지)
: :
: : 델파이에서 베껴쓰고 있는 메모리 매니지먼트 코드는 fastMM 의 간략화된 버전이라고 보면 되고.
: :
: : C++빌더는 파스칼로 컴파일 되어 있는 델파이 RTL, VCL에 종속되어 있기 때문에
: : 메모리 매니지먼트 구조도 종속성을 피할 수 없고.
: :
: : 64비트 컴파일 환경에선 _msize() 자체가 아예 구현되어 있지도 않고
: : 'Link with Dynamic RTL'로 지정하지 않으면 32비트로도 컴파일 할 수 없는 문제도 갖고 있지요.
: :
: :
: :
: : 델파이가 베껴 쓰고 있는 fastMM 메모리 매니지먼트 내부 구조를 변경해서
: : RTL과 C++ 런타임 코드를 후킹하지 않으면 정확한 사이즈를 얻는 게 델파이 때문에 구조적으로 불가능 합니다.
: :
: :
: : 델파이와 완전히 분리해서 C++ 독립적인 구조로 개발환경이 바뀌지 않는 이상.
: : 지금의 C++빌더는 족보도 없는 이상한 컴파일러에 불과한 거고.
: :
: : C++17 스펙으로 반드시 정의되어 있어야 할 scoped lock 조차도 구현되어 있지 않은 엉터리 컴파일러.
: : 이런 엉터리 컴파일러를 돈 받고 파는 뻔뻔함은 도대체 어디서 나오는 건지...
: :
: :
: :



답변:



TMonitor::Enter()와 TMonitor::Exit() 는 다음과 같이...

class procedure Enter(const AObject: TObject);
class procedure Exit(const AObject: TObject);

델파이 파스칼 언어로 구현되어 있는 코드에 불과해서

  TObject* obj;
  ...
  try {
    System::TMonitor::Enter(obj);
  } __finally {
    System::TMonitor::Exit(obj);
  }

위와 같이 델파이 처럼 try.. finally 블럭으로 코딩하는 패턴을 쓰고있을 게 뻔한데..
C++ 언어가 갖고있는 파워를 하나도 활용할 수 없으니 쓰지 마세요.

TList, TStringList, TMonitor 등은 다 쓸데 없는 것들에 불과한 겁니다.




멀티 클라이언트로 부터 SQL 쿼리를 inbound 패킷으로 받아서 데이타를 처리하는
데이타베이스 엔진을 만든다고 해 봅시다.

그리고 데이타베이스 엔진에서 SQL 트랜잭션을 지원해야 한다고 해 봅시다.


class CRecordSet
{
public:
   // SQL transaction lock
  std::mutex m;
  ...
};

std::thread t1 ([](auto& rs1, auto& rs2, ...N){
   std::scoped_lock lk(rs1.m, rs2.m, rs3.m...N);
   // process record set
   ...
   });

std::thread t2 ([](auto& rs1, auto& rs2, ...N){
   std::scoped_lock lk(rs1.m, rs2.m, rs3.m...N);
   // process record set
   ...
   });

....

std::thread tN ([](auto& rs1, auto& rs2, ...N){
   std::scoped_lock lk(rs1.m, rs2.m, rs3.m...N);
   // process record set
   ...
   });



C++17 에서 scoped_lock()은 variadic 템플릿으로 구현되어 있기 때문에...
위와 같이 임의의 N개의 다중 락을 인수로 사용할 수 있고

C++에선 RAII 패턴이 지원되므로 try...finally 블럭을 사용해야할 필요도 없고
예외가 발생하더라도 Lock이 안전하게 자동으로 릴리즈 됍니다.



더 나아가서...

N개의 데이타 Elements, N개의 다중 락, N개의 쓰레드가 복잡하게 사용되는 경우에는
반드시 Race Condition으로 인한 데드락이 발생하지 않게 프로그래밍 하는 게 중요한데

scoped_lock(...)을 사용하면 Dead Lock 걱정없이 멀티쓰레드 프로그래밍 로직을 간단하게 구현할 수 있지요.



그런데...

엠바 C++ 컴파일러는 C++17 스펙으로 반드시 정의되어 있어야 할 scoped lock 조차도 구현되어 있지 않습니다.

무늬만 C++17인 엉터리 컴파일러.