When is this lock-then-lock-again refactor a bad idea? - c++

Question

I've two sibling classes, A and B, and I want to refactor them so that A is the parent of B, so B can share A's code. But this refactor would mean, for one key function, locking a mutex twice instead of once. What reasons are there not to?
Class A
class A{
std::map<std::string, int> values;
std::mutex mutex;
public:
//init and access functions elided
void foo(std::string key, int v){
auto i = values.find(key);
if(i == values.end())return; //Actually report error
{
std::lock_guard<std::mutex> lock(mutex);
i->second = v;
}
}
};
Class B
class B{
std::map<std::string, int> values;
std::map<std::string, std::vector<int> > history;
std::mutex mutex;
public:
//init and access functions elided
void foo(std::string key, int v){
auto i = values.find(key);
if(i == values.end())return; //Actually report error
auto i2 = history.find(key);
if(i2 == history.end())return; //Actually report error
{
std::lock_guard<std::mutex> lock(mutex);
i->second = v;
i2->second.push_back(v);
}
}
};
The alternative to class B that I'd like to write is:
class C:public A{
std::map<std::string, std::vector<int> > history;
public:
//init and access functions elided
void foo(std::string key, int v){
A::foo(key,v);
auto i2 = history.find(key);
if(i2 == history.end())return; //Actually report error
{
std::lock_guard<std::mutex> lock(mutex);
i2->second.push_back(v);
}
}
};
The access functions also use the mutex, to lock their reads. For the purpose of this question assume foo() gets called a lot more than any other function in these classes. We can also assume all calls to foo() are serialized; the mutex is there for other threads that use the access functions.
Q. Splitting one mutex lock into two locks done in serial cannot add any new deadlock potential?
Q. Is there a bigger code smell from code duplication with class A and class B, or from "hiding" the extra mutex lock in the base class call?
Q. Is the extra overhead of locking twice going to be trivial compared to the other actions I am doing in foo()? I.e. I'm guessing that inserts into maps and vectors takes at least 10 times as long as locking a mutex.
Q. class C now allows a read of values that is out of sync with a read of history (i.e. if another thread grabbed the lock in the middle of C::foo()). If that turns out to be a problem, is going back to "duplicate the code in class A and B" the only design choice?

Answer 1

How about this alternative, which adds a foo_impl function that returns the lock, so it can be re-used in C::foo:
class A
{
std::map<std::string, int> values;
std::mutex mutex;
public:
//init and access functions elided
void foo(std::string key, int v)
{
foo_impl(key, v);
}
protected:
std::unique_lock<std::mutex> foo_impl(std::string key, int v)
{
auto i = values.find(key);
if (i == values.end()) return {}; //Actually report error
std::unique_lock<std::mutex> lock(mutex);
i->second = v;
return lock;
}
};
class C : public A
{
std::map<std::string, std::vector<int> > history;
public:
//init and access functions elided
void foo(std::string key, int v)
{
auto i2 = history.find(key);
if (i2 == history.end()) return; //Actually report error
if (auto lock = A::foo_impl(key,v))
i2->second.push_back(v);
}
};
This ensures the updates to A::values and C::history are done under a single lock, so A::values cannot get updated again between the two locks in your original C::foo.

Answer 2

I don't understand why you think it's necessary to lock twice, this seem like what you want to do?
class A{
std::map<std::string, int> values;
std::mutex mutex;
protected:
void foo_unlocked(std::string key, int v){
auto i = values.find(key);
if(i != values.end())
i->second = v;
}
};
class C:public A{
std::map<std::string, std::vector<int> > history;
public:
//init and access functions elided
void foo(std::string key, int v){
auto i2 = history.find(key);
if(i2 == history.end())
return; //Actually report error
std::lock_guard<std::mutex> lock(mutex);
i2->second.push_back(v);
foo_unlocked(key, v); // do the operation in A but unlocked...
}
};