Thread problem using Dinkumware V3.08 STL 
Author Message
 Thread problem using Dinkumware V3.08 STL

P. J. Plauger assures me that if each thread is using it's own
container (map/vector), then there is no need for any type of locking,
etc. needed when accessing them.  From looking at the V3.08 header
files, I don't have any problem believing this.

I have a Win32 console app that creates five threads, and each thread
creates a local instance of my class.  My class makes heavy use of STL
maps and vectors, but none of the threads are sharing any data.

When I run multiple instances of the program on a multiprocessor box,
at some point one of the instances will generate an exception.  It
always appears to be in the destruction of one of the maps.

Does anybody have any insight or suggestions on what might be causing
this problem?

I don't expect someone to debug all of my code for me, but I have
stared at if for weeks, and I'm having no luck finding anything that
looks like a problem.

Things I have looked for:

1) static class variables
2) static function variables
3) Proper copy constructor and operator= for classes in containers
4) Buffer Over/under writes

Thanks for any help!
Mike Baker



Mon, 17 May 2004 23:16:37 GMT  
 Thread problem using Dinkumware V3.08 STL
Well, a couple easy-to-check things first:

are you sure you're linking in the Multi-Threaded Run Time Library?

I assume this isn't COM and so no ::CoInitializeEx() is needed, but are you
initializing the RTL by beginning each thread via _beginthread() or
_beginthreadex()?

A few debugging suggestions in case you haven't already tried them:

(1) set a flag in your object (the one held in the map): clear it in its
dtor, and assert() there if the dtor is called with the flag cleared.

(2) wrap the map in a simple object and do #1 in its ctor/dtor.

(3) OutputDebugString() with ThreadId and address of each map as it's
allocated and destructed.  Painful to trace, but sometimes very helpful.

(4) If you NULL all pointers after delete'ing them, does the problem change?

(5) If you only have one thread, does the problem eventually occur anyway?

Oh, wait, I just read your message again more carefully: the problem occurs
only when multiple instances of the program are run?  Unless you're using
shared memory, that should be irrelevant, leading me to wonder whether
you're not just running out of memory and not handling that exactly right.
E.g., perhaps one of your objects (member of the map) fails to create
completely, and the failure leaves the map in an indeterminate state which
causes a problem at cleanup time.  This is definitely one of the hardest
things to get right with the STL (e.g., see Herb Sutter's "Exceptional C++"
or someone's "More Effective STL").

Well, that's all I can think of.  Hopefully of some use to you.

Larry West
SkyDesk, Inc.


Quote:
> P. J. Plauger assures me that if each thread is using it's own
> container (map/vector), then there is no need for any type of locking,
> etc. needed when accessing them.  From looking at the V3.08 header
> files, I don't have any problem believing this.

> I have a Win32 console app that creates five threads, and each thread
> creates a local instance of my class.  My class makes heavy use of STL
> maps and vectors, but none of the threads are sharing any data.

> When I run multiple instances of the program on a multiprocessor box,
> at some point one of the instances will generate an exception.  It
> always appears to be in the destruction of one of the maps.

> Does anybody have any insight or suggestions on what might be causing
> this problem?

> I don't expect someone to debug all of my code for me, but I have
> stared at if for weeks, and I'm having no luck finding anything that
> looks like a problem.

> Things I have looked for:

> 1) static class variables
> 2) static function variables
> 3) Proper copy constructor and operator= for classes in containers
> 4) Buffer Over/under writes

> Thanks for any help!
> Mike Baker



Wed, 19 May 2004 01:35:47 GMT  
 Thread problem using Dinkumware V3.08 STL
Hi,

Could you please tell me whether the problem exists when executing a single
instance of your program?

I am standing by for your reply.

Regards,
HuangTM

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. ? 2001 Microsoft Corporation. All rights
reserved.



Fri, 21 May 2004 18:01:56 GMT  
 Thread problem using Dinkumware V3.08 STL

Quote:
> Could you please tell me whether the problem exists when executing a single
> instance of your program?

Yes, I have had the problem with a single instance of the program.
The key seems to be multiple threads, and gets worse with more
processors.  If I limit my program to one thread, I have never had a
failure.

Thanks in advance!
Mike Baker



Fri, 21 May 2004 23:43:29 GMT  
 Thread problem using Dinkumware V3.08 STL
Hi,

Did you apply the latest Visual Studio Service Pack 5?
Based on my experience, map may cause dead lock in Multithreaded
Application before.

Regards,
HuangTM

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. ? 2001 Microsoft Corporation. All rights
reserved.



Mon, 24 May 2004 20:11:18 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. MFC ActiveX control using Dinkumware v3.08 won't load in debugger

2. Dinkum STL V3.08

3. Dinkum v3.08 Release linking problem

4. Strange error message using 08 or higher for index to array

5. STL fixes from Dinkumware have problems

6. dinkumware stl link problem

7. problems with Dinkumware STL lib for WinCE

8. STL fixes from Dinkumware have problems

9. Dinkumware STL Problem in WinCE with EVC++

10. problems with Dinkumware STL lib for WinCE

11. Dinkumware problem: gutted code, it loads, but not when calling Dinkumware

12. Dinkum V3.08 : "unreached code " warning message

 

 
Powered by phpBB® Forum Software