multithreaded dll - what is going on in std::_Lockit?
in [Visual C]
|
From: Scott McPhillips [MVP] on 20 Mar 2007 12:45 alan.lemon(a)gmail.com wrote: > In my particular application I am really not concerned with being > thread safe. Is there any way to get rid of these calls? > If you are referring to heap allocations, it won't work. If the heap is not threadsafe the application will soon crash. -- Scott McPhillips [VC++ MVP]
From: Tom Widmer [VC++ MVP] on 20 Mar 2007 12:54 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. As others have said, these relate to locking occuring in the standard library functions. There are several ways you can reduce the level of locking caused by standard library calls: 1. Make sure _HAS_ITERATOR_DEBUGGING is defined to 0. Iterator debugging involves a huge amount of locking an unlocking of a single global debug mutex. You are testing a release build, right? 2. Reduce the amount of dynamic memory alloction you do. 3. Use a more performant multithreaded memory allocator, such as hoard or google's allocator (http://goog-perftools.sourceforge.net/doc/tcmalloc.html). Tom
From: Ben Voigt on 20 Mar 2007 13:22
<alan.lemon(a)gmail.com> wrote in message news:1174407741.847432.194310(a)b75g2000hsg.googlegroups.com... > 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? > If you don't need to create an object from one thread and delete it on another, then create a separate unsynchronized heap for each thread. You can still pass objects back and forth, but you can only ever free the object using the same heap (and therefore thread if you couple it like this) that allocated it. HeapCreate(HEAP_NO_SERIALIZE) is your ticket. You may want to store the heap handle in thread local storage. |