Thread: Why is my prog aborting after 283 or so threads?

I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after spawning 283 or so threads, it stops running and 'Aborted' is printed. It doesn't matter if I spawn them one after each other, or only 10 at a time, or if the threads only last 1 second or if they all stick around until the 283rd thread is spawned. Every combination I've tried results in the prog aborting at about the 283rd thread spawn. Does this sound familiar to anybody? Is there something my thread must do to properly shut itself down? Does it need to call some kind of procedure to announce it is going away for proper cleanup? I couldn't see anything in the examples like that. And is there documentation explaining the examples? I failed to find any. My thread procedure: void updatethread(void* inparams) { thread_params *tparam; tparam=(thread_params *)inparams; int local_threadid = tparam->param1; std::string DID = tparam->param2; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " running. " "UPDATE for " << DID << std::endl; } // wait some secs (just for debug, remove when real work is being done) boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 2; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " Exiting. " << std::endl; } { boost::mutex::scoped_lock scoped_lock(numthreads_mutex); --activethreads; } } MAIN calls it with this: //spawn thread tparam.param1=threadid; tparam.param2=dids[i]; boost::thread *pt; pt = thrds.create_thread(thread_adapter(&updatethread, (void*)&tparam)); Thanks, Tim

What version of Boost? I seem to remember a Boost.Threads thread local storage problem that would cause a problem after about that many threads, which should be fixed in the latest release (1.32 from only a few days ago). I'm not sure if that's your problem, but if it is I recommend giving 1.32 a try. Mike "Tim Laplaca" <tlaplaca@voiceglo.com> wrote in message news:5D27A17F676E8648B2C4CB5DC4E40E0D9338DD@porsche.corp.voiceglo.com...
I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after spawning 283 or so threads, it stops running and 'Aborted' is printed.
It doesn't matter if I spawn them one after each other, or only 10 at a time, or if the threads only last 1 second or if they all stick around until the 283rd thread is spawned. Every combination I've tried results in the prog aborting at about the 283rd thread spawn.
Does this sound familiar to anybody?
Is there something my thread must do to properly shut itself down? Does it need to call some kind of procedure to announce it is going away for proper cleanup? I couldn't see anything in the examples like that.
And is there documentation explaining the examples? I failed to find any.
My thread procedure:
void updatethread(void* inparams) {
thread_params *tparam; tparam=(thread_params *)inparams;
int local_threadid = tparam->param1; std::string DID = tparam->param2;
{ boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " running. " "UPDATE for " << DID << std::endl; }
// wait some secs (just for debug, remove when real work is being done) boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 2; boost::thread::sleep(xt);
{ boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " Exiting. " << std::endl; }
{ boost::mutex::scoped_lock scoped_lock(numthreads_mutex); --activethreads; }
}
MAIN calls it with this:
//spawn thread tparam.param1=threadid; tparam.param2=dids[i]; boost::thread *pt; pt = thrds.create_thread(thread_adapter(&updatethread, (void*)&tparam));
Thanks, Tim
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Tim Laplaca wrote:
I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after spawning 283 or so threads, it stops running and 'Aborted' is printed.
Take a look at: http://www.kegel.com/c10k.html#threaded and check your sizes. -- Alexander Nasonov
participants (3)
-
Alexander Nasonov
-
Michael Glassford
-
Tim Laplaca