Recent changes to bugs

Eventual pthread resource exhaustion uncaught exception

2012-05-10T11:17:44Z

(Affects pthreads i.e. Linux implementation of boost)
In a situation where pools are being continually created and destroyed, the terminate_all_workers() doesnt properly join all the threads that were created by the pool.
As a result, eventually pthread_create() will fail inside the worker_thread<pool_type>::create_and_attach()
Because this is silent, instead, the next pool created deadlocks waiting for a condition that will never be sent because there was no thread created to send it but the pool doesnt realise this because it doesnt properly detect creation errors.

On a linux x86-64 OpenSuse 11.4 with intel 8 core CPU, this occurs after 2752 unjoined threads exist.
On a linux amd64 phenom quad core debian squeeze, there seems to have been 32768 unjoined threads created

There are two problems:
(a) the resource exeption within create_and_attach() is silently trapped. This caused me a lot of head scratching for a while...
(b) the terminate_all_workers method() does not join all exiting threads, because it runs before the thread destruction hook worker_destructed() has a chance to add the thread to the terminated_workers vector

I resolved this by counting the number of times the thread creation is called for the pool, and using that to make sure that many threads are waiting to be cleaned up before exiting.

Update: after I fixed this problem, I read bug 2910301 and suspect it is the same problem. I also think the fix supplied is just as valid as what worked for me.

I would still class eating the resource exception as an additional bug, the caller should know if it is not possible to create the pool in the desired manner.

To demonstrate the problem using unpatched 0.2.5:

(Run the example)
g++ -I threadpool-0_2_5-src/threadpool/ -lboost_thread -lpthread example.cpp
./a.out

After 172 iterations thread creation failed as 2562 threads were finished but never joined
because the exception is silently caught, output of 'task' stops after 172
when I inserted 'throw' in the handler, instead after 172 iterations the program aborted

On a different computer, amd64 debian squeeze, I managed 2047 loops instead

After my patch, this runs to completion

Error in pool destruction

2010-10-20T20:59:45Z

Hello. I have the following set of events:

1. I have a .dll that uses fifo_pool.

2. Pool gets destructed.

2.1. terminate_all_workers (wait_for_all_tasks shutdown policy) notify all workers to quit.

2.2. All workers were already finished with their tasks, so, there's no wait

2.3.1. Worker threads gets notification they should be quit, they clean up and, at the end, they add themselves to the m_terminated_workers collection

2.3.2. Back in terminate_all_workers; m_terminated_workers collection is iterated and all threads there are joined. However, at this point, m_terminated_workers collection IS EMPTY. The sequence was notify all and then no wait, so, threads are ready to be run, but, they are possibly not scheduled yet.

2.4. Pool destructor is done.

3. My dll is unloaded.

4. Worker threads eventually get scheduled and BOOM - process crashes because there's no more code to execute.

Does this explanation makes any sense? Is there a fix for this? Tnx.

unusable shutdown policy

2010-02-19T02:26:07Z

I'm wondering how to shutdown the thread pool. I have used the shutdown policy, but it can't work because the "void terminate_all_workers(bool const wait)" function is a private member function.

Memory Leak fix

2009-12-07T21:35:56Z

I have fixed the memory leak issue which exists in the version 0.2.5, Fixed version of 0.2.5 you can find in the attachment.

Memory leak

2009-09-22T17:43:50Z

Here is the valgrind output from the threadpool specific part of my daemon which grows to about 3G in an hour. Any help appreciated.

==11428== Thread 1:
==11428==
==11428== 7,200 bytes in 50 blocks are possibly lost in loss record 13 of 14
==11428== at 0x4021E22: calloc (vg_replace_malloc.c:397)
==11428== by 0x4010C7B: _dl_allocate_tls (in /lib/ld-2.7.so)
==11428== by 0x42CF672: pthread_create@@GLIBC_2.1 (in /lib/i686/cmov/libpthread-2.7.so)
==11428== by 0x4045F76: boost::thread::start_thread() (in /usr/lib/libboost_thread-mt.so.1.35.0)
==11428== by 0x80E0CC7: boost::thread::thread<boost::_bi::bind_t<void, boost::_mfi::mf0<void, boost::threadpool::detail::worker_thread<boost::threadpool:
:detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler, boost::threadpool::static_size, boost::
threadpool::resize_controller, boost::threadpool::wait_for_all_tasks> > >, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::threadpool::detail::
worker_thread<boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler, boost::
threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks> > > > > > >(boost::_bi::bind_t<void, boost::_mfi::mf0<
void, boost::threadpool::detail::worker_thread<boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::th
readpool::fifo_scheduler, boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks> > >, boost::_bi::list
1<boost::_bi::value<boost::shared_ptr<boost::threadpool::detail::worker_thread<boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<bo
ost::function_base> >, boost::threadpool::fifo_scheduler, boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_
all_tasks> > > > > >) (thread.hpp:151)
==11428== by 0x80E0DE4: boost::threadpool::detail::worker_thread<boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler, boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks>>::create_and_attach(boost::shared_ptr<boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler, boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks> > const&) (worker_thread.hpp:105)
==11428== by 0x80E4B93: boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler, boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks>::resize(unsigned) volatile (pool_core.hpp:349)
==11428== by 0x80E4B93: boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler, boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks>::resize(unsigned) volatile (pool_core.hpp:349)
==11428== by 0x80E5187: boost::threadpool::static_size<boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler, boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks> >::init(boost::threadpool::detail::pool_core<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler, boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks>&, unsigned) (size_policies.hpp:75)
==11428== by 0x80E59EF: boost::threadpool::thread_pool<boost::function0<void, std::allocator<boost::function_base> >, boost::threadpool::fifo_scheduler,boost::threadpool::static_size, boost::threadpool::resize_controller, boost::threadpool::wait_for_all_tasks>::thread_pool(unsigned) (pool.hpp:103)
==11428== by 0x80E5D97: Server::Server(int volatile&, boost::shared_ptr<FileDescriptor>, boost::shared_ptr<Core>, unsigned, unsigned, unsigned, unsigned, unsigned, bool, std::string const&, std::string const&, std::string const&, unsigned) (server.h:84)

Memory leak on Windows

2009-04-06T00:18:37Z

Using Visual Studio 9, we have detected memory leaks when using the threadpool library. Unfortunately, we do not have the time right now to debug it for you, so I am posting this in the hopes that you can take a look and maybe it is a quick fix for you. Basically, this method:

static void create_and_attach(shared_ptr<pool_type> const & pool)
{
shared_ptr<worker_thread> worker(new worker_thread(pool));
if(worker)
{
worker->m_thread.reset(new boost::thread(bind(&worker_thread::run, worker)));
}
}

creates new worker threads. As best I can tell, this is where the memory is being leaked. It looks like the worker and/or the pool are not getting released properly. I looked through and see that you are using shared pointers, so maybe the reference count is not getting decremented properly. Again, I haven't had the time to look more closely at it. To reproduce, basically just use this code (run it from Visual Studio):

#include <boost/threadpool.hpp>

#ifdef WIN32
#include <crtdbg.h>
#endif

int main()
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

boost::threadpool::pool pool( 1 );

return 0;
}

Please let me know if you need any clarification or additional information. Thanks!

hangs up in boost::threadpool::pool::~pool

2008-05-20T09:49:27Z

I am using threadpool with Boost 1.35 and it hangs up when I try to destroy boost::threadpool::pool object.
Debugging shows that none of my functions are executing.
The problem seems to be that one of the worker threads doesn't get m_task_or_terminate_workers_event event.