Critical Sections
-
Today I profiled [using Rational Quantify] one of our applications in which a certain action took more and more time. I found the reason of the problem, but also noticed something else very strange. Although the application runs most of the time in single-threaded mode, it has some actions that run multi-threaded. Therefore, some important datastructures were protected with a CriticalSection. I noticed that the CriticalSection functions take about 15% of the total CPU time of the application. But there's more. Consider the following small application:
#include <stdio.h> #include <stdlib.h> #include <windows.h> CRITICAL_SECTION Cs; const long MAX_LOOPS=10000; main () { InitializeCriticalSection (&Cs); for (long i=0;i -
Today I profiled [using Rational Quantify] one of our applications in which a certain action took more and more time. I found the reason of the problem, but also noticed something else very strange. Although the application runs most of the time in single-threaded mode, it has some actions that run multi-threaded. Therefore, some important datastructures were protected with a CriticalSection. I noticed that the CriticalSection functions take about 15% of the total CPU time of the application. But there's more. Consider the following small application:
#include <stdio.h> #include <stdlib.h> #include <windows.h> CRITICAL_SECTION Cs; const long MAX_LOOPS=10000; main () { InitializeCriticalSection (&Cs); for (long i=0;iMy guess is that the profiler isn't telling the truth. The fact that it isn't showing EnterCriticalSection rings alarm bells. Run the program in the debugger and verify that EnterCriticalSection is indeed being called. It must be. If there is a bottleneck it will be at EnterCriticalSection when another thread has it locked. LeaveCriticalSection should be instantaneous. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com