Re: [Boost-users] [BOOST THREAD] Threads Spawning Unexpectedly

Subject: Re: [Boost-users] [BOOST THREAD] Threads Spawning Unexpectedly
From: Nigel Rantor (wiggly_at_[hidden])
Date: 2009-04-26 21:01:27

Terrimane Pritchett wrote:
> Hello,
> 
> I have taken interest in using Boost Threads in my project.  I have a 
> strange issue that I am trying to debug.
> 
> I spawn N boost::thread instances because I know exactly how many I 
> need.  My program crashes after a time on a boost::bad_lexical_cast 
> exception.  I have placed a wrapper around boost::lexical_cast which 
> uses a boost::recursive_mutex and boost::lock_guard combination to 
> prevent multiple threads from calling boost::lexical_cast at the same time.

What made you think that the exception was being thrown becasue the 
program is multithreaded?

> Still, my project invariably chokes on boost::bad_lexical_cast being 
> thrown when I can verify the cast should work i.e. everything works as 
> expected in my single threaded implementation.

Have you checked the information that the exception is returning to you?

Have you got the data that caused the exception?

> My real cause for alarm is this....when I act to debug my project I 
> always discover there are more active boost::thread instances than I 
> have explicitly created.  I only create boost::thread instances in one 
> location.

Could you please elaborate as to why you think you have more threads 
than expected? How many? What other libraries are you using that may 
create threads?

> Here is what my code more or less looks like - this is all I do with 
> boost::threads currently - how are more than N boost::threads spawning 
> where N is the number of elements in an arbitrary stl container which 
> itself is not allowed to change in size?

Posting code that won't compile is worse than not posting anything at all.

A cursory glance at the lexical_cast source leads me to think that 
tracking down the data that caused the bad_lexical_cast to be thrown 
should be your first job.

Until you do that I wouldn't waste any time trying to create wrappers 
around libraries that may already be thread-safe.

Someone who is more familliar with the lexical_cast code may be able to 
say one-way or another. If you had hard evidence it was a threading 
issue I'd spend some more time on it, but I'd put my money on the 
bad_lexical_cast being thrown because it could not perform the requested 
conversion, and nothing to do with threads.

Let us know how you get on with trying to track down the data that 
caused the exception to be thrown.

Regards,

   Nigel