TCriticalSection vs TMultiReadExclusiveWriteSynchronizer

오늘 갑자기 두 넘의 성능이 궁금해져서 간단하게 테스트 프로그램을 만들어서 실행해 봤습니다.  테스트 코드는 귀찮아서 생략합니다 ^^;

일단, 싱글 스레드에서 락을 걸고 락을 푸는 일을 반복 해 본 결과는 거의 동일한 성능을 보여주었습니다.  이런 경우에 사용 될 일은 없겠지만, 기본적인 비용 문제를 살펴보았습니다.

이어서 스레드 두 개를 만들어서 TCriticalSection은 Enter와 Leave를 반복하고, TMultiReadExclusiveWriteSynchronizer의 경우에는 BeginRead와 EndRead를 반복 해 보았습니다.  허걱!  결과는 의외로 TCriticalSection의 승!!

이상해서 소스 코드를 살펴보니 TMultiReadExclusiveWriteSynchronizer 내부에는 디버깅용 코드가 많은 것을 확인, Release 모드로 컴파일 해서 다시 테스트 진행한 결과, 역시 TMultiReadExclusiveWriteSynchronizer의 경우 BeginRead의 부하가 거의 없는 것으로 나타났습니다. (즉, 테스트 환경에서는 두 배의 성능 효과)

주의 할 점은 락이 걸리는 시간이 매우 짧은 경우에는 TCriticalSection이 훨씬 유리하다는 점 입니다.  교착이 일어나지 않았을 경우의 코드의 실행 비용은 비슷하지만, 교착이 일어났을 경우의 실행 비용은 TMultiReadExclusiveWriteSynchronizer가 압도적으로 많습니다.  정확한 수치를 연구 할 정도로 흥미로운 주제는 아니라서 포기 합니다. ^^;  제 PC의 테스트 상황에서 3배가 조금 안되는 비용이 발생합니다.

또 하나의 주의 사항을 다시 강조하자면, 디버깅 모드에서는 역효과가 있습니다. !!

결론, 락이 오래 지속되는 상황에서라면 TMultiReadExclusiveWriteSynchronizer이 유리하다.  하지만, 간단한 메모리 공유의 문제라면 오히려 역효과가 날 수 있다.

http://msdn.microsoft.com/ko-kr/library/br244843(v=vs.110).aspx  이런 넘도 있었군요 ^^;  테스트 결과 어떠한 경우에도 TCriticalSection 보다 우수한 성능을 보여줍니다.  대신 재귀적인 락을 사용 할 수 없다는 단점이 있습니다.  TMultiReadExclusiveWriteSynchronizer의 경우처럼 Read(Shared)의 경우 스레드 개수만큼의 이득을 보이고 있습니다.  즉, Read는 락을 공유하기 때문에 얼마나 Read 락을 자주 하게 되느냐가 그대로 이득으로 나타난다고 생각하시면 됩니다.

델파이용 유닛은 다음 링크를 참고하시기 바랍니다.

http://code.google.com/p/ryulib4delphi/source/browse/trunk/XE2/SRWLock.pas