Re: [Boost-users] two boost.threads taking much longer than one

From: Thomas S. Urban (scottu_at_[hidden])
Date: 2004-10-11 10:58:37

On Mon, Oct 11, 2004 at 12:20:10, Andrew Chapman spake thusly:
> Caleb Epstein wrote:
> >On Thu, 07 Oct 2004 18:14:53 +0100, Andrew Chapman > The thread 
> >functor objects are being passed a lot of references (about
> >
> >>20) to some very large std::vectors. One thread always reads/writes
> >>from the start of the vectors to their midpoint, and the second
> >>thread from (midpoint+1) to the end of the vectors.
> >
> >
> >Perhaps you could provide some code?
> 
>     // resize all the furXXX std::vectors
>     furGen.allocate(...);
> 
>     boost::thread_group threads;
> 
>     CalcCurvesThread thread1Obj(furGen, 0, midPoint,
>       furCurves, furRootUVs, furRootPositions, furRootNormals,
>       furRootDu, furRootDv, furRootDpDuv, guideCurves,
>       guideLookupTable, furDesc, 1.0);
> 
>     CalcCurvesThread thread2Obj(furGen, midPoint+1, nCurves-1,
>       furCurves, furRootUVs, furRootPositions, furRootNormals,
>       furRootDu, furRootDv, furRootDpDuv, guideCurves,
>       guideLookupTable, furDesc, 1.0);
> 
>     threads.create_thread(thread1obj);
>     threads.create_thread(thread2obj);
> 
>     threads.join_all();
> 
> 
> >Are the threads using any sort of synchronization between themselves?
> >Perhaps you're spending a lot of time contending on a mutex if so.
> >If they're just operating on some shared resources (the vectors) with
> >no locking, they should certainly run faster than the single-threaded
> >case on a dual CPU machine.
> 
> No, there is no need for any synchronization, as far as I can tell. Each 
> thread is only reading from and writing to different areas of the
> pre-allocated vectors (thread1 to the first half of the vectors, thread2 
> to the second half).
> 
> It was my assumption that the new child threads are sharing all the data
> with the host process. However, after watching the threads running so
> slowly, and it appearing as through they're sleep/wait'ing on system
> resources, I was wondering if somehow all the stack data in my large 
> data vectors wasn't being copied to and from the threads.

I would bet that there are hidden synchronization costs in the code you
are interested in.  Can't tell by looking at your code, though.
Possibilities:

- std::string usage.  Are you copying strings in the thread functor,
  from the vector or elsewhere?  If so, you the COW used for
  std::strings involves a lock.

- smart pointer usage (especially copying/assignment) that involves
  locking, e.g. boost::shared_ptr does this depending on build settings

- allocation.  Lots of little allocations in multi-threaded code can be
  a source of serialization (heap is locked for allocations). You might
  see this with explicit allocations or with objects that use the
  free store if the scope of those objects is small.  An example is
  std::string (in addition to the other problem) - if you used one as a
  buffer in your functor code, you could be thrashing the heap.

All of this is guesswork, you might want to construct the minimal
amount of compilable-code necessary to reproduce the problem and post
it.

Scott