Re: [Boost-users] boost::bind correct way

On 13.09.2010 21:05, Kraus Philipp wrote:

Hi,

I'm using boost::bind for creating a thread group. My code shows this way: boost::thread_group l_threadgroup; for(std::size_t i=0; i < boost::thread::hardware_concurrency(); ++i) l_threadgroup.create_thread( boost::bind( &ncd<T>::multithread_deflate_symmetric, this, i ) );

The code runs within the class method "symmetric" and should be called from the self object the multithread_deflate_symmetric. My class "ncd" is a template class. I debug the code on a amd64 Gentoo Linux with valgrind 3.5 and get a "data race condition". Valgrind shows this message:

==6914== Possible data race during read of size 8 at 0x7fefff6d0 by thread #1 ==6914== at 0x4C2B138: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==6914== by 0x6152B10: boost::thread::start_thread() (in /opt/library/Boost/1.44/lib/libboost_thread.so.1.44.0) ==6914== by 0x414B50: boost::thread::thread, boost::_bi::list2, boost::_bi::value<unsigned long> > > >(boost::_bi::bind_t, boost::_bi::list2, boost::_bi::value<unsigned long> > >, boost::disable_if, boost::_bi::list2, boost::_bi::value<unsigned long> > >&, boost::detail::thread_move_t, boost::_bi::list2, boost::_bi::value<unsigned long> > > > >, boost::thread::dummy*>::type) (in main)

==6914== by 0x419F4D: ncd<double>::symmetric(std::vectorstd::string > const&, bool const&) (in main) ==6914== by 0x40B10F: main (in main)

==6914== This conflicts with a previous write of size 8 by thread #2 ==6914== at 0x4C2B263: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)

Do I use boost::bind in the correct way? Thanks

I think race conditions in your application have little to do with using bind() (with whose usage I see no problem). Try to identify the write reported by Valgrind at: ==6914== This conflicts with a previous write of size 8 by thread #2 ==6914== at 0x4C2B263: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) Whatever common data is shared by your threads in the group, it should only be accessed with the proper locking, or should be split so that at most one thread accesses any given portion of the data (so it is no longer shared). The object pointed to by this is also a candidate for such data shared in common, which you should check. Regards, Timothy Madden