# Critical section question

This topic is 2450 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello everyone,

I have a function that ask for a reference to a constant std::vector.
Example:
bool DoSomething(const std::vector<int>& data);
The thing is, I would like this function to be multi-threaded. I've learned, by reading tutorials, that any data that is not local, should be protected by for example a mutex. But the tutorials assumed that the data that needed protected would be modified by the multi-threaded function.

Now the question is, does any data that is constant or is guaranteed to not be modified need a kind of protection? I assume here that only one function will access the data, although this function will be run in multiple threads.

##### Share on other sites
Just because DoSomething() accepts the vector via a reference-to-const doesn't mean the vector is actually constant. Even if it is const, you have to be careful with member functions that are logically const, but do actually mutate memory in some way. I doubt any implementation of std::vector would do anything like this (though using debug iterators *might* be fishy...) but look out for things with caches which have methods declared as const, but aren't const as far as memory mutation is concerned.

If you can guarantee (by inspection of related code) that the object and the memory used for its implementation aren't modified, then yes, multiple threads can read from it concurrently.

##### Share on other sites

If by "guaranteed to not be modified" you mean "guaranteed to not be modified by this function", the answer is that it still needs protection.

The reason is that presumably other threads may be changing the data, and it is theoretically possible for this function's read of the data to be corrupted by a concurrent write by another thread.

If your program is able to guarantee that no threads will be writing to the data during execution of this function, then you shouldn't need protection at this level. Simultaneous reads are safe on most architectures.

Edited by vreality

##### Share on other sites
As mentioned, being constant means your function cannot modify it, but another thread easily could be while your function is reading from it.

The typical way of handling this is to “lock” the resource your function wants to read (in this case a vector) and “unlock” it when it is done reading from it.
If you are worried that this could happen, you should subclass the vector and add some locking routines to it. After calling Lock(), the resource enters a read-only state which allows any number of threads to simultaneously read from it. Write operations are blocked until Unlock() has been called the same number of times as Lock().

L. Spiro

##### Share on other sites

The typical way of handling this is to “lock” the resource your function wants to read (in this case a vector) and “unlock” it when it is done reading from it.

If data is going to be manipulated, it must be locked everywhere it is accessed, not just where it is read.

If you are worried that this could happen, you should subclass the vector and add some locking routines to it.
[/quote]
std::vector is not designed to be subclassed. If you did want to add locking at this granularity, it would be preferable to write a wrapper that locks and forwards. Or to design a system that leverages RAII to handle unlocking, e.g. scoped_lock.

After calling Lock(), the resource enters a read-only state which allows any number of threads to simultaneously read from it. Write operations are blocked until Unlock() has been called the same number of times as Lock().
[/quote]
You would need to have an API that supports the distinction locking for reading and writing to support this. Otherwise you can only support mutual exclusion, you could not support multiple readers.

@OP The better solutions involving multi-threading synchronisation are usually a high level architectural choices, not low level locking. For example, if the vector isn't excessively big, it can be cheaper to have multiple copies rather than trying to enforce locking.

##### Share on other sites
I agree with everything you said, but I figured the original poster would be trying to avoid re-arranging his code to add high-level managers etc.

And yes making a Lock()/Unlock() system that allows multiple reads but not write is non-trivial. Which is why I thought about it for a while but was not able to provide a suggestion as to how he could do this.
I was hoping he would try a stack of critical section locks, find out it is mutually exclusive, and post back with a question on how to do this. Teehee.
I didn’t have time to dream up a solution with the Interlocked* functions (assuming Win32 API), as my limited experience with them would require me to study the whole set of functions to see which ones do what.

L. Spiro

##### Share on other sites
If you need a multiple reader single writer lock one option is a boost shared_mutex.

##### Share on other sites

@OP The better solutions involving multi-threading synchronisation are usually a high level architectural choices, not low level locking. For example, if the vector isn't excessively big, it can be cheaper to have multiple copies rather than trying to enforce locking.

I am not really sure what you mean with high level architectural choices and therefore I don't understand what difference between those and low level locks.

The vector has pointers to objects used in the Physics Engine I'm making. And as the world can contain any number of objects from 0 to the maximum range of an unsigned integer.

As for other functions accessing the data.
There is are two functions that can modify the data:
- A master function (There will only one running at once), this will wait for all child threads to finish.
- A child function (There will be mutiple of these running at once), this is the function my question is about and will not modify any data inside the vector or modify the vector itself.

• 17
• 11
• 12
• 9
• 49
• ### Forum Statistics

• Total Topics
631395
• Total Posts
2999758
×