Generic parallel programming question.

[isnork]

Hi,

While documenting myself about parallel programming, I read that when trying to write into a shared resource, i.e. a vector, a lock should be used to prevent race conditions and global side effects.

My question is: if I can guarantee that the threads accesing that resource will never interfere with each other, is the lock needed?.

For example, having a std::vector<MyObject> and two threads that will retrieve an object from the vector via its id and then update some of the object data. If before the threads retrieve the objects the id's are checked to make sure that they are different, can global side effects occur?

Thanks in advance.

[kev82]

My question is: if I can guarantee that the threads accesing that resource will never interfere with each other, is the lock needed?.

If you are not going to alter the vector in any way (that includes inadvertently), and as long as the objects are different, then as far as I'm aware, the STL is thread safe and you are ok without a lock. Beware of objects with hidden copy-on-write semantics though.

If before the threads retrieve the objects the id's are checked to make sure that they are different, can global side effects occur?

How do you do this check?

[isnork]

If you are not going to alter the vector in any way (that includes inadvertently)

I don't push or remove an object from the vector. I only update some values of the objects that are stored in the vector. So is this thread safe?

How do you do this check?

I'm working with Intel TBB. I do the check in a root class, before spawning the child classes that will access the vector. I spawn as many child classes as different id's are.

[hanst99]

If you are not going to alter the vector in any way (that includes inadvertently), and as long as the objects are different, then as far as I'm aware, the STL is thread safe and you are ok without a lock. Beware of objects with hidden copy-on-write semantics though.

That is, if you aren't altering the vector in any of the threads. You can't even safely read a multi-word number without locking if other threads might have access to it.

[kev82]

Double check the thread safety of the STL you are using, but in principle, there shouldn't be any issues with that. As long as your different instances of MyObject don't step on each other.

[Cubbi]

two threads that will retrieve an object from the vector via its id and then update some of the object data.

The vector will be fine, but if some thread reads the value after another thread updated it, you have a data race unless the value is atomic, protected by a mutex, or otherwise synchronized.

[isnork]

The vector will be fine, but if some thread reads the value after another thread updated it, you have a data race unless the value is atomic, protected by a mutex, or otherwise synchronized.

Ok. It seems that I need locks. Thanks!.

The vector will be fine

And if instead of a std::vector I use, for example, MyObject* vec = new MyObject[ size ], the vector is still safe to access?

Thanks people!

[kev82]

Why do you need locks, I thought you were launching a separate thread for each member of the vector? Have I misunderstood? There is no need for locks in that case.

[isnork]

Why do you need locks, I thought you were launching a separate thread for each member of the vector?

I misread, sorry. My fault!