Ответ 1
Как я могу это сделать?
Альтернатива 1
Один подход заключается в создании типа с boost::scoped_lock:
class t_scope_lock {
public:
t_scope_lock(MyClass& myClass);
...
private:
boost::scoped_lock d_lock;
};
и MyClass, чтобы предоставить доступ к мьютексам для этого типа. Если этот класс написан специально для MyClass, я бы просто добавил его как внутренний класс MyClass::t_scoped_lock.
Альтернатива 2
Другим подходом было бы создание промежуточного типа для использования с блокировкой области видимости, которая могла бы быть конвертируемой в конструктор блокировки области (пользовательский). Затем типы могут выбирать, как они считают нужным. Многим людям может не нравиться блокировка пользовательской области, но это позволит вам легко указать доступ по вашему желанию и с хорошей степенью контроля.
Альтернатива 3
Иногда лучше добавить слой абстракции для MyClass. Если класс является сложным, это вряд ли является хорошим решением, потому что вам нужно будет предоставить множество вариантов, которые выглядят следующим образом:
{
boost::scoped_lock lock(f->GetScopedLock());
f->LockedFunc1();
f->LockedFunc2();
}
Альтернатива 4
Иногда вы можете использовать другую блокировку (например, внутреннюю и внешнюю).
Альтернатива 5
Как и в случае С# 4, в некоторых случаях вы можете использовать рекурсивную или readwrite-блокировку.
Альтернатива 6
Вы можете использовать заблокированный тип-обертку, чтобы выборочно предоставлять доступ к частям интерфейса типа.
class MyClassLockedMutator : StackOnly {
public:
MyClassLockedMutator(MyClass& myClass);
// ...
void LockedFunc1() { this->myClass.LockedFunc1(); }
void LockedFunc2() { this->myClass.LockedFunc2(); }
private:
MyClass& myClass;
boost::scoped_lock d_lock; // << locks myClass
};
MyClass f;
MyClassLockedMutator a(f);
a.LockedFunc1();
a.LockedFunc2();
Является ли это разумным?
Имейте в виду, что я понятия не имею, каковы точные ограничения вашей программы (следовательно, несколько альтернатив).
Альтернативы # 1, # 2, # 3 и # 6 (практически) не имеют накладных расходов на производительность и во многих случаях имеют незначительную дополнительную сложность. Они, однако, синтаксически шумны для клиента. IMO, принудительная правильность, которую компилятор может проверить (по мере необходимости), более важен, чем минимизация синтаксического шума.
Альтернативы # 4 и # 5 - это хорошие способы введения дополнительных сбоев/конфликтов или блокировок/одновременных ошибок и ошибок. В некоторых случаях это простая замена, заслуживающая внимания.
Когда правильность, производительность и/или другие ограничения имеют решающее значение, я думаю, что имеет смысл абстрагироваться или инкапсулировать эти сложности, даже если это требует синтаксического шума или уровня абстракции. Я делаю это, потому что слишком легко вносить изменения, даже если я написал и поддерживал всю программу. Для меня это более сложный случай видимости и совершенно разумный, если он используется правильно.
Некоторые примеры
Прокрутите вниз до main - этот пример довольно неорганизован, потому что он демонстрирует несколько подходов в одном:
#include <iostream>
#include <boost/thread.hpp>
class MyClass;
class MyClassOperatorBase {
public:
/* >> public interface */
bool bazzie(bool foo);
protected:
MyClassOperatorBase(MyClass& myClass) : d_myClass(myClass) {
}
virtual ~MyClassOperatorBase() {
}
operator boost::mutex & ();
MyClass& getMyClass() {
return this->d_myClass;
}
const MyClass& getMyClass() const {
return this->d_myClass;
}
protected:
/* >> required overrides */
virtual bool imp_bazzie(bool foo) = 0;
private:
MyClass& d_myClass;
private:
/* >> prohibited */
MyClassOperatorBase(const MyClassOperatorBase&);
MyClassOperatorBase& operator=(const MyClassOperatorBase&);
};
class MyClass {
public:
MyClass() : mLock() {
}
virtual ~MyClass() {
}
void LockedFunc1() {
std::cout << "hello ";
}
void LockedFunc2() {
std::cout << "world\n";
}
bool bizzle(bool foo) {
boost::mutex::scoped_lock lock(this->mLock);
return this->imp_bizzle(foo);
}
protected:
virtual bool imp_bizzle(bool foo) {
/* would be pure virtual if we did not need to create it for other tests. */
return foo;
}
private:
class t_scope_lock {
public:
t_scope_lock(MyClass& myClass) : d_lock(myClass.mLock) {
}
private:
boost::mutex::scoped_lock d_lock;
};
protected:
friend class MyClassOperatorBase;
private:
boost::mutex mLock;
};
MyClassOperatorBase::operator boost::mutex & () {
return this->getMyClass().mLock;
}
bool MyClassOperatorBase::bazzie(bool foo) {
MyClass::t_scope_lock lock(this->getMyClass());
return this->imp_bazzie(foo);
}
class TheirClassOperator : public MyClassOperatorBase {
public:
TheirClassOperator(MyClass& myClass) : MyClassOperatorBase(myClass) {
}
virtual ~TheirClassOperator() {
}
bool baz(bool foo) {
boost::mutex::scoped_lock lock(*this);
return this->work(foo);
}
boost::mutex& evilClientMove() {
return *this;
}
protected:
virtual bool imp_bazzie(bool foo) {
return this->work(foo);
}
private:
bool work(bool foo) {
MyClass& m(this->getMyClass());
m.LockedFunc1();
m.LockedFunc2();
return foo;
}
};
class TheirClass : public MyClass {
public:
TheirClass() : MyClass() {
}
virtual ~TheirClass() {
}
protected:
virtual bool imp_bizzle(bool foo) {
std::cout << "hallo, welt!\n";
return foo;
}
};
namespace {
/* attempt to restrict the lock visibility to MyClassOperatorBase types. no virtual required: */
void ExampleA() {
MyClass my;
TheirClassOperator their(my);
their.baz(true);
// boost::mutex::scoped_lock lock(my); << error inaccessible
// boost::mutex::scoped_lock lock(my.mLock); << error inaccessible
// boost::mutex::scoped_lock lock(their); << error inaccessible
boost::mutex::scoped_lock lock(their.evilClientMove());
}
/* restrict the lock visibility to MyClassOperatorBase and call through a virtual: */
void ExampleB() {
MyClass my;
TheirClassOperator their(my);
their.bazzie(true);
}
/* if they derive from my class, then life is simple: */
void ExampleC() {
TheirClass their;
their.bizzle(true);
}
}
int main(int argc, const char* argv[]) {
ExampleA();
ExampleB();
ExampleC();
return 0;
}