Re: [Threads-devel] Concurrent vector assignment

Subject: Re: [Threads-devel] Concurrent vector assignment
From: Gregory Peele ARA/CFD (gpeele_at_[hidden])
Date: 2011-12-29 17:50:33

David,

Meant to chime in earlier, see detailed comments interspersed with your questions below.  Summary version is that I think what you described should work in practice, with some caveats for unlikely platform-dependent corner cases.  Though if you are using something other than MSVC or GNU C++, make sure to check the vector implementation like Stefan recommended.

Gregory Peele, Jr.
Senior Scientist
Applied Research Associates, Inc.
Central Florida Division

> -----Original Message-----
> From: threads-devel-bounces_at_[hidden] [mailto:threads-devel-
> bounces_at_[hidden]] On Behalf Of Stefan Küppers
> Sent: Thursday, December 29, 2011 5:16 PM
> To: Discussions about the boost.thread library
> Subject: Re: [Threads-devel] Concurrent vector assignment
> 
> Hello David,
> check if the implementation of the "vector"-class used by you is
> thread-safe or not.
> If not, you are responsible to asure the correct usage of the vector in
> a multi-threaded environment.
> Potential problems are all modifications of member variables of the
> vector class, for example
> if two threads resize the vector simultaneously.
> Regards,
> Stefan.
> 
> 
> Am 26.12.2011 12:38, schrieb David White:
> > Please forgive me if this has already been answered - I just couldn't
> seem to find hints anywhere.
> >
> > I have a vector of objects which I would like to process
> concurrently.  Through the use of a thread-safe queue, I can guarantee
> that only one thread will work on any one vector element at a time.
> Hence, each element is modified once by a single thread via iterators.
> >
 [Gregory Peele ARA/CFD] Assuming std::vector, yes?  Such as from MSVCRT, GNU libstdc++, etc.?  It should also go without saying that each thread must have its own copy of iterators and those cannot be shared between threads.

> > My question is - do I need a mutex and associated locking for this
> vector assignment behaviour?  In other words, does each thread need to
> lock the vector before it can modify an element in which no other
> thread is interested in?
> >
> > During this operation, no 'modifying' functions (e.g. push_back,
> pop_back, insert, erase, etc) are called.
 
[Gregory Peele ARA/CFD] I believe that for any practical implementation of std::vector and any reasonable element type, this would work without a mutex for this use case since you do not alter its size, capacity, element order, or any state that could affect other threads while any threads are touching the std::vector, though I'm not sure if C++-11 actually makes any guarantees about it (C++-98 certainly doesn't).  

As for corner cases, I suspect there could be platform-dependent memory model issues if either your vector elements are small enough to require read/mask/write assignment on a platform (assuming very unlikely, don't think x86 or AMD64 does this) or if one thread writes an element and another thread later reads it without a memory barrier in between.  Presumably after all threads have completed editing the vector you use a mutex + wait condition or something similar to synchronize with whatever ends up using that result, which would induce an appropriate barrier.

Hopefully that gives you a good starting point?

> >
> > Thanks in advance.
> >
> > Kind regards, David.
> > _______________________________________________
> > threads-devel mailing list
> > threads-devel_at_[hidden]
> > http://lists.boost.org/mailman/listinfo.cgi/threads-devel
> 
> _______________________________________________
> threads-devel mailing list
> threads-devel_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/threads-devel