1

Possible Duplicate:
Is stl vector concurrent read thread-safe?

I have a multi-threaded program that has a certain amount of workers, each worker has a 'workerID' which is essentially just a unique integer for that thread. I want to use a vector of structs to manage these threads. my question is, if thread 4 wants to access myVector[4] at the same time as thread 8 wants to access myVector[8], am I going to have a problem?

Community
  • 1
  • 1
Whyrusleeping
  • 889
  • 2
  • 9
  • 20

4 Answers4

4

If you have setup the vector before entering into multi-threading scenario, and then you want to only read the vector from multiple threads, without modifying it, then it is thread-safe. You can read even the same element from more than two threads simultaneously, just make sure that no thread modifies the vector in any way. Treat the vector and all its elements as read-only.

However, for modification, none of the containers from the Standard Library are thread-safe. You need to implement the synchronization yourself.

C++11 has introduced many synchronization primitives, so if your compiler supports, you can use them.

Nawaz
  • 353,942
  • 115
  • 666
  • 851
  • Removed my downvote. I'm not going to upvote though as this is a dup so it's more constructive to direct the OP to the [other question](http://stackoverflow.com/questions/7455982/is-stl-vector-concurrent-read-thread-safe) which has plenty of references. – Jonathan Wakely Jun 21 '12 at 18:36
  • @JonathanWakely: I've voted to close, but I'm not going to remove my answer, as there is no harm in it. – Nawaz Jun 21 '12 at 18:38
  • One further question, if one other thread locks a mutex for the vector to change a value in it, will the other threads that are merely reading their given spots need to worry about anything? – Whyrusleeping Jun 21 '12 at 19:04
  • 1
    @Whyrusleeping: If a thread writes, then it should be locked for all other threads, even for reading. That is, when one thread modifies, no other thread is allowed to write/modify and read/inspect. – Nawaz Jun 21 '12 at 19:10
3

No. Managing the vector class across threads is not safe, you need to use some synchronization mechanism (e.g. a mutex) to protect read/write access to the std::vector<> instance.

πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
  • As the question Thomas mentions above says, if the data is set up beforehand, and all the threads are doing *only* reads, then it's safe. If one thread is doing writes and no other threads are reading that element, it is probably safe, but I'm not sure how strictly the standard guarantees it (due to issues with read-modify-write across elements stored in the same word). – bdow Jun 21 '12 at 18:26
  • It guarantees it absolutely, see http://stackoverflow.com/a/11020907/981959 – Jonathan Wakely Jun 21 '12 at 18:28
  • @JonathanWakely: This is true for cx11 standards, isn't it?? That wasn't mentioned by the OP explicitely. But anyway, good to know ... – πάντα ῥεῖ Jun 21 '12 at 18:52
  • It wasn't mentioned, but I was responding to @bdow and the C++03 standard doesn't say _anything_ about threads so the C++11 standard is the only relevant one – Jonathan Wakely Jun 21 '12 at 19:00
1

You won't have problems (afaik), unless they use the same element.

But if they delete something, or push_back something, etc. it is a bad idea.

To be on the safe side, use a lock.

manasij7479
  • 1,665
  • 1
  • 14
  • 22
  • Thank you, I was considering using a lock anyways, my only reservation (as im new to multithreading) is the performance impact on using locks. – Whyrusleeping Jun 21 '12 at 18:21
1

Generally speaking std::vector is not thread safe. But what you want to do is safe. If you are only reading the vector in multiple threads this will work. It will also work if each thread only writes to its own offset. What will definitely not work is if you start doing things like resizing the vector in threads, or if multiple threads want to write to the same offset.

Rafael Baptista
  • 11,181
  • 5
  • 39
  • 59