No exemplo abaixo, se ignorarmos o mutex por um segundo, a cópia elision poderá eliminar as duas chamadas para o construtor de cópia

user_type foo()
{
  unique_lock lock( global_mutex );
  return user_type(...);
}

user_type result = foo();

Agora, as regras para a remoção de cópias não mencionam o encadeamento, mas estou imaginando se isso realmente deveria acontecer além desses limites. Na situação acima, a cópia final, no inter-thread da máquina abstrata lógica, ocorre após o lançamento do mutex. Se, no entanto, as cópias forem omitidas, a estrutura de dados do resultado será inicializada no mutex, portanto, o encadeamento ocorrerá antes do lançamento do mutex.

Ainda tenho que pensar em um exemplo concreto de como a elisão de cópia pode realmente resultar em uma condição de corrida, mas a interferência na sequência de memória parece ser um problema. Alguém pode dizer definitivamente que não pode causar um problema ou alguém pode dar um exemplo que possa realmente quebra

Para garantir que a resposta não se refira apenas a um caso especial, observe que, de acordo com minha leitura, ainda é permitido que oculte uma cópia, se eu tiver uma declaração comonew (&result)( foo() ). Isso é,result não precisa ser um objeto de pilha.user_type próprio @ também pode funcionar com dados compartilhados entre thread

Respond: Escolhi a primeira resposta como a discussão mais relevante. Basicamente, já que o padrão diz que a elisão pode acontecer, o programador só precisa ter cuidado quando isso ocorre através dos limites da sincronização. Não há indicação se esse é um requisito intencional ou acidental. Ainda não temos nenhum exemplo mostrando o que poderia dar errado, por isso talvez não seja um problema de qualquer maneira.