multithreaded dll - what is going on in std::_Lockit?
in [Visual C]
|
From: alan.lemon on 20 Mar 2007 10:42 I am working in VS2005 and I have created a multithreaded dll. For this particular project I need my code to be as fast as possible so I have been using a profiler to see where any bottle necks exist in my project. I am using Compuware's community edition profiler and interestingly a lot of the time that my project spends is in : std::_Lockit::_Lockit(int) std::_Lockit::~_Lockit() RtlEnterCriticalSection RtlLeaveCriticalSection I have done some searching around, but I don't understand what these objects/functions do and if I can do anything about it. Any help would be greatly appreciated.
From: Scott McPhillips [MVP] on 20 Mar 2007 11:05 alan.lemon(a)gmail.com wrote: > I am working in VS2005 and I have created a multithreaded dll. For > this > particular project I need my code to be as fast as possible so I have > been using a profiler to see where any bottle necks exist in my > project. I am using Compuware's community edition profiler and > interestingly a lot of the time that my project spends is in : > > std::_Lockit::_Lockit(int) > std::_Lockit::~_Lockit() > RtlEnterCriticalSection > RtlLeaveCriticalSection > > I have done some searching around, but I don't understand what these > objects/functions do and if I can do anything about it. Any help would > be greatly appreciated. > They provide interthread synchronization. If more than one thread is trying to access the same data then they cause all but one of the threads to stall or suspend until the shared resource is available for exclusive access. One significant such shared resource is the heap. If you have a lot of memory allocation/delete/reallocation in multiple threads all these accesses to the heap manager delay each other. Anything you can do to reduce heap changes for very busy objects is likely to improve this. -- Scott McPhillips [VC++ MVP]
From: adebaene on 20 Mar 2007 12:15 On 20 mar, 15:42, alan.le...(a)gmail.com wrote: > I am working in VS2005 and I have created a multithreaded dll. For > this > particular project I need my code to be as fast as possible so I have > been using a profiler to see where any bottle necks exist in my > project. I am using Compuware's community edition profiler and > interestingly a lot of the time that my project spends is in : > > std::_Lockit::_Lockit(int) > std::_Lockit::~_Lockit() > RtlEnterCriticalSection > RtlLeaveCriticalSection > > I have done some searching around, but I don't understand what these > objects/functions do and if I can do anything about it. Any help would > be greatly appreciated. It's the internal function that is called when you try to enter a critical section. If your app spends a lot of time inside it, it means there is contention in your application (eg, different threads are competing for locking the same critical section, so some of them are put to sleep). Working out where are the contentions (on which critical section) is not an easy task. Here are a few possibilities: - try to reduce the number of threads in your app - this may require a lot of architecture changes and is not always doable. - try to reduce the number of heap allocations / deallocations. As Scott as explained, the heap allocator is protected by a critical section, and there is often a lot of contention on it. - if you are using critical sections using a C++ wrapper class, you can add some logging in the Enter/Exit function to see which critical section(s) is /are often acquired. Arnaud MVP - VC
From: alan.lemon on 20 Mar 2007 12:22 On Mar 20, 9:05 am, "Scott McPhillips [MVP]" <org-dot-mvps-at- scottmcp> wrote: > alan.le...(a)gmail.com wrote: > > I am working in VS2005 and I have created a multithreaded dll. For > > this > > particular project I need my code to be as fast as possible so I have > > been using a profiler to see where any bottle necks exist in my > > project. I am using Compuware's community edition profiler and > > interestingly a lot of the time that my project spends is in : > > > std::_Lockit::_Lockit(int) > > std::_Lockit::~_Lockit() > > RtlEnterCriticalSection > > RtlLeaveCriticalSection > > > I have done some searching around, but I don't understand what these > > objects/functions do and if I can do anything about it. Any help would > > be greatly appreciated. > > They provide interthread synchronization. If more than one thread is > trying to access the same data then they cause all but one of the > threads to stall or suspend until the shared resource is available for > exclusive access. > > One significant such shared resource is the heap. If you have a lot of > memory allocation/delete/reallocation in multiple threads all these > accesses to the heap manager delay each other. Anything you can do to > reduce heap changes for very busy objects is likely to improve this. > > -- > Scott McPhillips [VC++ MVP] In my particular application I am really not concerned with being thread safe. Is there any way to get rid of these calls?
From: Arnie on 20 Mar 2007 12:45
>> One significant such shared resource is the heap. If you have a lot of >> memory allocation/delete/reallocation in multiple threads all these >> accesses to the heap manager delay each other. Anything you can do to >> reduce heap changes for very busy objects is likely to improve this. >> >> -- >> Scott McPhillips [VC++ MVP] > > In my particular application I am really not concerned with being > thread safe. Is there any way to get rid of these calls? You should be. As Scott said and others have repeated, synchronizing access to the heap can be a real bottleneck in a multi-threaded app that runs on n processors where n > 1. A single processor isn't much of a problem because only one thread can run at a time anyway. On a multi processor/core machine, they're all vying for heap access. Depending upon how much threads are tyrying to access the heap, the app might actually run a bit slower on, say, a four processor mcahine. Our solution was to allocate as much memory up front as possible reducing heap access as much possible while running. No, this wasn't easy but did show much improved performance. - Arnie |