Reputation: 1178
I have a std::map
that is going to be modified from multiple threads, and I have a mutex to lock these writes. However, the map must occasionally be used during a long-running operation, and it would not be good to hold the lock during this entire operation, blocking all of those writes.
I have two questions about this:
For example:
class Foo {
void writeToMap(Bar &bar, Baz &baz) {
// lock mutex
map[bar] = baz;
// unlock mutex
}
std::map<Bar, Baz> getMapCopy() {
// lock mutex (Is this necessary?)
std::map<Bar, Baz> copy (map);
// unlock mutex
return copy;
}
std::map<Bar, Baz> map;
};
void expensiveOperation(Foo &f) {
std::map<Bar, Baz> mapCopy = f.getMapCopy();
// Can I safely read mapCopy?
}
Upvotes: 0
Views: 641
Reputation: 1281
Sounds like the copy operation itself is not thread safe, the issue being atomicity of copying 64-bit values. You copy the first 4 bytes, while the second 4 is being modified by another thread leaving you with inconsistent 8 bytes.
Please have a look here: Is copy thread-safe?
If you manage to create a consistent copy, however, I do not see why not...
Upvotes: 3
Reputation: 409482
You have undefined behavior in that code, as you return a reference to a local variable. This locla variable will be destructed once the function returns, and you now have a reference to a destructed object.
If you want to return a copy then you have to return by value, so it would be e.g.
std::map<Bar, Baz> getMapCopy() {
return map;
}
And if you use the mutexes and locks from the C++11 standard thread library you don't need an explicit unlock, the mutex will be unlocked with the destruction of the lock.
Upvotes: 2