Vamos começar com um pouco de código:
class A
{
using MutexType = std::mutex;
using ReadLock = std::unique_lock<MutexType>;
using WriteLock = std::unique_lock<MutexType>;
mutable MutexType mut_;
std::string field1_;
std::string field2_;
public:
...
Coloquei alguns aliases de tipo bastante sugestivos lá, dos quais realmente não tiraremos proveito no C ++ 11, mas se tornarão muito mais úteis no C ++ 14. Seja paciente, vamos chegar lá.
Sua pergunta se resume a:
Como escrevo o construtor de movimento e o operador de atribuição de movimento para esta classe?
Começaremos com o construtor de movimento.
Construtor de movimento
Observe que o membro mutexfoi feito mutable. Estritamente falando, isso não é necessário para os membros de movimento, mas estou assumindo que você também deseja membros de cópia. Se não for esse o caso, não há necessidade de fazer o mutex mutable.
Ao construir A, você não precisa travar this->mut_. Mas você precisa bloquear o mut_do objeto a partir do qual está construindo (mover ou copiar). Isso pode ser feito assim:
A(A&& a)
{
WriteLock rhs_lk(a.mut_);
field1_ = std::move(a.field1_);
field2_ = std::move(a.field2_);
}
Observe que tivemos que construir os membros de por padrão thisprimeiro e, em seguida, atribuir-lhes valores somente depois de a.mut_ser bloqueado.
Mover Atribuição
O operador de atribuição de movimentação é substancialmente mais complicado porque você não sabe se algum outro encadeamento está acessando o lhs ou o rhs da expressão de atribuição. E, em geral, você precisa se proteger contra o seguinte cenário:
x = std::move(y);
y = std::move(x);
Aqui está o operador de atribuição de movimentação que protege corretamente o cenário acima:
A& operator=(A&& a)
{
if (this != &a)
{
WriteLock lhs_lk(mut_, std::defer_lock);
WriteLock rhs_lk(a.mut_, std::defer_lock);
std::lock(lhs_lk, rhs_lk);
field1_ = std::move(a.field1_);
field2_ = std::move(a.field2_);
}
return *this;
}
Observe que deve-se usar std::lock(m1, m2)para bloquear os dois mutexes, em vez de apenas bloqueá-los um após o outro. Se você bloqueá-los um após o outro, então quando dois threads atribuem dois objetos na ordem oposta como mostrado acima, você pode obter um deadlock. O objetivo std::locké evitar esse impasse.
Copiar construtor
Você não perguntou sobre os membros copiadores, mas podemos também falar sobre eles agora (se não for você, alguém vai precisar deles).
A(const A& a)
{
ReadLock rhs_lk(a.mut_);
field1_ = a.field1_;
field2_ = a.field2_;
}
O construtor de cópia se parece muito com o construtor de movimento, exceto que o ReadLockalias é usado em vez do WriteLock. Atualmente esses dois apelidos std::unique_lock<std::mutex>e, portanto, realmente não faz nenhuma diferença.
Mas em C ++ 14, você terá a opção de dizer o seguinte:
using MutexType = std::shared_timed_mutex;
using ReadLock = std::shared_lock<MutexType>;
using WriteLock = std::unique_lock<MutexType>;
Isso pode ser uma otimização, mas não definitivamente. Você terá que medir para determinar se é. Mas com essa mudança, pode-se copiar a construção do mesmo rhs em vários threads simultaneamente. A solução C ++ 11 força você a tornar tais threads sequenciais, mesmo que o rhs não esteja sendo modificado.
Copiar Atribuição
Para completar, aqui está o operador de atribuição de cópia, que deve ser bastante autoexplicativo depois de ler sobre todo o resto:
A& operator=(const A& a)
{
if (this != &a)
{
WriteLock lhs_lk(mut_, std::defer_lock);
ReadLock rhs_lk(a.mut_, std::defer_lock);
std::lock(lhs_lk, rhs_lk);
field1_ = a.field1_;
field2_ = a.field2_;
}
return *this;
}
E etc.
Quaisquer outros membros ou funções livres que acessem Ao estado também precisarão ser protegidos se você espera que vários threads sejam capazes de chamá-los de uma vez. Por exemplo, aqui está swap:
friend void swap(A& x, A& y)
{
if (&x != &y)
{
WriteLock lhs_lk(x.mut_, std::defer_lock);
WriteLock rhs_lk(y.mut_, std::defer_lock);
std::lock(lhs_lk, rhs_lk);
using std::swap;
swap(x.field1_, y.field1_);
swap(x.field2_, y.field2_);
}
}
Observe que se você depende apenas de std::swapfazer o trabalho, o bloqueio estará na granularidade errada, bloqueando e desbloqueando entre os três movimentos que std::swapexecutariam internamente.
Na verdade, pensar sobre swappode fornecer uma visão sobre a API que você pode precisar fornecer para uma API "thread-safe" A, que em geral será diferente de uma API "não thread-safe", devido ao problema de "granularidade de bloqueio".
Observe também a necessidade de proteção contra "troca automática". "self-swap" deve ser um ambiente autônomo. Sem a autoverificação, bloquearíamos recursivamente o mesmo mutex. Isso também pode ser resolvido sem a verificação automática usando std::recursive_mutexfor MutexType.
Atualizar
Nos comentários abaixo, Yakk está muito infeliz por ter que construir coisas por padrão nos construtores de copiar e mover (e ele tem razão). Se você tiver uma opinião forte o suficiente sobre esse problema, a ponto de estar disposto a gastar memória com ele, você pode evitá-lo desta forma:
Adicione quaisquer tipos de bloqueio de que você precisa como membros de dados. Esses membros devem vir antes dos dados que estão sendo protegidos:
mutable MutexType mut_;
ReadLock read_lock_;
WriteLock write_lock_;
E então nos construtores (por exemplo, o construtor de cópia) faça isso:
A(const A& a)
: read_lock_(a.mut_)
, field1_(a.field1_)
, field2_(a.field2_)
{
read_lock_.unlock();
}
Opa, Yakk apagou seu comentário antes que eu tivesse a chance de completar esta atualização. Mas ele merece crédito por empurrar esse problema e encontrar uma solução para essa resposta.
Atualização 2
E dyp veio com esta boa sugestão:
A(const A& a)
: A(a, ReadLock(a.mut_))
{}
private:
A(const A& a, ReadLock rhs_lk)
: field1_(a.field1_)
, field2_(a.field2_)
{}