Subject: Re: [Threads-devel] Concurrent vector assignment
From: Clark Gaebel (cg.wowus.cg_at_[hidden])
Date: 2011-12-29 22:44:49
If you're not using any vector modification functions from multiple
threads, try decomposing the vector into a pointer + size structure
using vector<>.data() and vector<>.size(). Then pass this around,
giving you deterministic behavior.pect this
However, I suspect this is a problem elsewhere in your code. Try
cutting things out until you get as minimal of a test case as
possible. You may be surprised by the removal that fixes the problem.
On Mon, Dec 26, 2011 at 6:38 AM, David White <dawhite32_at_[hidden]> wrote:
> 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.
> 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.
> Thanks in advance.
> Kind regards, David.
> threads-devel mailing list