Начнем с мьютексов. Простейший враппер, часто встречающийся в исходном коде, выглядит следующим образом:
class CMutex {
public:
CMutex( … some initializers…);
~CMutex();
void lock();
void unlock();
private:
::pthread_mutex_t m_mutex;
С первого взгляда, все выглядит отлично, но на самом деле это не так. Представим себе что объект содержащий этот мьютекс попадает, например, в std::map. Что интересно некоторое время все будет в порядке, до тех пор, пока map не наполнится до определенного размера и не реаллокирует свою память. При этом произойдет перемещение CMutex:m_mutex, и мьютекс после этого перестанет работать. Чаще всего это выглядит как deadlock, но эффекты могут быть совершенно разными.
Как этого избежать? Есть два варианта. Первый – недопускать попадания CMutex в контейнеры. Но в данном случае мы полностью полагаемся на программиста использующего этот враппер. Лучше этого не делать. Второй вариант намного лучше. Нам нужно объявить в CMutex конструктор копирования и оператор присвоения, но не определять их тело. В результате код CMutex будет выглядеть так:
class CMutex
{
public:
CMutex(int _mutexType = PTHREAD_MUTEX_FAST_NP);
CMutex(const CMutex&);
CMutex& operator=(const CMutex&);
~CMutex();
void lock();
void unlock();
private:
::pthread_mutex_t m_mutex;
::pthread_mutexattr_t m_mutexAttr;
};
inline
CMutex::CMutex(int _mutexType)
{
::pthread_mutexattr_init(&m_mutexAttr);
::pthread_mutexattr_settype(&m_mutexAttr, _mutexType);
::pthread_mutex_init(&m_mutex, &m_mutexAttr);
}
inline
CMutex::~CMutex()
{
::pthread_mutexattr_destroy(&m_mutexAttr);
::pthread_mutex_destroy(&m_mutex);
}
inline
void CMutex::lock()
{
switch(::pthread_mutex_lock(&m_mutex))
{
case EDEADLK: throw Exception::Mutex::Deadlock();
case EINVAL: throw Exception::Mutex::Initialization();
}
}
inline
void CMutex::unlock()
{
switch(::pthread_mutex_unlock(&m_mutex))
{
case EPERM: throw Exception::Mutex::Permission();
case EINVAL: throw Exception::Mutex::Initialization();
}
}
и т.д., без тел для CMutex(const CMutex&) и operator=(const CMutex&). При компиляции, если CMutex каким либо образом попадет в контейнер, будет выдана ошибка компиляции.
Стоит отметить, что такое решение рекомендуется применять для всех структур, копирование для которых запрещено.
С одной проблемой мы разобрались. Продолжим дальше.В приведенном выше исходном коде при deadlock мьютекса (если он создавался с _mutexType = PTHREAD_MUTEX_ERRORCHECK_NP) будет выброшен некий exception Exception::Mutex::Deadlock. Насколько такой подход к обработке ошибок нам подходит?
Представим себе следующую ситуацию. Есть некое дерево содержащие указатели на некие объекты. Мы можем запирать мьютексом все дерево и каждый его лист в отдельности. Т.е. можно использовать такой алгоритм - заперли дерево, нашли лист, заперли лист, отпустили дерево, поработали с листом, отпустили лист.
Представим себе что в при вызове этого алгоритма мы получили exception Exception::Mutex::Deadlock или Exception::Mutex::Permission. Как нам корректно обработать эту ситуацию, что бы наше приложение продолжило работать?
Единственное толковое решение, которое спасет нас в некоторых случаях, это паттерн MutexLocker. Реализовать его можно следующим образом:
class CMutex {
...
class CLocker
{
public:
CLocker(CMutex &_mutex) : m_mutex(_mutex) { m_mute.lock(); }
~CLocker(){ m_mutex.unlock(); }
private:
CMutex &m_mutex;
};
...
};
Используется он таким образом:
...
{
CMutex::CLocker lock(somemutex);
... /* do some job */
};
...
Таким образом ответственность за запирание мьютекса ложится на стек. При создании CMutex::CLocker мьютекс запирается, а при его уничтожении отпирается. Преимущество этого решения в том что, всегда будет вызван CMutex.unlock() и программисту не придется следить за этим самому. В тоже время это не дает гарантии что программист не будет использовать lock() на уже запретом CLocker мьютексе. Конечно данное решение не поможет нам в том случае если мы получаем EPERM при вызове ::pthread_mutex_unlock(...). Но такая ошибка является уже очень серьезной и говорит о нарушении стратегии взаимодействия потоков.
