std :: unique_lock <std :: mutex> ou std :: lock_guard <std :: mutex>?

Eu tenho dois casos de uso.

A. Eu quero sincronizar o acesso por dois threads em uma fila.

B. Quero sincronizar o acesso de dois threads a uma fila e usar uma variável de condição porque um dos threads aguardará o conteúdo ser armazenado na fila pelo outro thread.

Para o caso de uso AI, veja o exemplo de código usando std::lock_guard<>. Para o caso de uso de BI, veja o exemplo de código using std::unique_lock<>.

Qual é a diferença entre os dois e qual deles devo usar em qual caso de uso?

A diferença é que você pode bloquear e desbloquear a std::unique_lock. std::lock_guardserá bloqueado apenas uma vez na construção e desbloqueado na destruição.

Portanto, para o caso de uso B, você definitivamente precisa de um std::unique_lockpara a variável de condição. No caso A, depende se você precisa trancar a proteção novamente.

std::unique_lockpossui outros recursos que permitem, por exemplo: ser construído sem bloquear o mutex imediatamente, mas criar o wrapper RAII (veja aqui ).

std::lock_guardtambém fornece um invólucro RAII conveniente, mas não pode bloquear vários mutexes com segurança. Pode ser usado quando você precisar de um wrapper para um escopo limitado, por exemplo: uma função de membro:

class MyClass{
    std::mutex my_mutex;
    void member_foo() {
        std::lock_guard<mutex_type> lock(this->my_mutex);            
        /*
         block of code which needs mutual exclusion (e.g. open the same 
         file in multiple threads).
        */

        //mutex is automatically released when lock goes out of scope           
};

Para esclarecer uma pergunta por chmike, por padrão std::lock_guarde std::unique_locksão os mesmos. Portanto, no caso acima, você pode substituir std::lock_guardpor std::unique_lock. No entanto, std::unique_lockpode ter um pouco mais de sobrecarga.

Note que hoje em dia deve-se usar em std::scoped_lockvez de std::lock_guard.

lock_guarde unique_locksão praticamente a mesma coisa; lock_guardé uma versão restrita com uma interface limitada.

A lock_guardsempre mantém uma trava de sua construção até sua destruição. A unique_lockpode ser criado sem o bloqueio imediato, pode ser desbloqueado a qualquer momento da existência e pode transferir a propriedade do bloqueio de uma instância para outra.

Então você sempre usa lock_guard, a menos que precise dos recursos do unique_lock. A condition_variableprecisa de um unique_lock.

Use, a lock_guardmenos que você precise ser capaz de unlockalterar manualmente o mutex sem destruir o lock.

Em particular, condition_variabledesbloqueia seu mutex ao dormir após chamadas para wait. É por isso que a lock_guardnão é suficiente aqui.

Existem certas coisas comuns entre lock_guarde unique_locke certas diferenças.

Mas, no contexto da pergunta, o compilador não permite o uso de uma lock_guardcombinação com uma variável de condição, porque quando um thread chama a espera de uma variável de condição, o mutex é desbloqueado automaticamente e quando outros threads / threads notificam e o segmento atual é invocado (sai da espera), o bloqueio é adquirido novamente.

Este fenômeno é contra o princípio de lock_guard. lock_guardpode ser construído apenas uma vez e destruído apenas uma vez.

Portanto, lock_guardnão pode ser usado em combinação com uma variável de condição, mas unique_lockpode ser (porque unique_lockpode ser bloqueado e desbloqueado várias vezes).

Eles não são realmente os mesmos mutexes, lock_guard<muType>tem quase o mesmo que std::mutex, com uma diferença de que a vida útil termina no final do escopo (chamado D-tor), portanto, uma definição clara sobre esses dois mutexes:

lock_guard<muType> possui um mecanismo para possuir um mutex pela duração de um bloco com escopo definido.

E

unique_lock<muType> é um invólucro que permite bloqueio adiado, tentativas de bloqueio com tempo limitado, bloqueio recursivo, transferência da propriedade do bloqueio e uso com variáveis ​​de condição.

Aqui está um exemplo de implementação:

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <functional>
#include <chrono>

using namespace std::chrono;

class Product{

   public:

       Product(int data):mdata(data){
       }

       virtual~Product(){
       }

       bool isReady(){
       return flag;
       }

       void showData(){

        std::cout<<mdata<<std::endl;
       }

       void read(){

         std::this_thread::sleep_for(milliseconds(2000));

         std::lock_guard<std::mutex> guard(mmutex);

         flag = true;

         std::cout<<"Data is ready"<<std::endl;

         cvar.notify_one();

       }

       void task(){

       std::unique_lock<std::mutex> lock(mmutex);

       cvar.wait(lock, [&, this]() mutable throw() -> bool{ return this->isReady(); });

       mdata+=1;

       }

   protected:

    std::condition_variable cvar;
    std::mutex mmutex;
    int mdata;
    bool flag = false;

};

int main(){

     int a = 0;
     Product product(a);

     std::thread reading(product.read, &product);
     std::thread setting(product.task, &product);

     reading.join();
     setting.join();


     product.showData();
    return 0;
}

Neste exemplo, eu usei o unique_lock<muType>comcondition variable

Como já foi mencionado por outros, std :: unique_lock rastreia o status de bloqueio do mutex, para que você possa adiar o bloqueio até depois da construção do bloqueio e desbloqueá-lo antes da destruição do bloqueio. std :: lock_guard não permite isso.

Parece não haver razão para as funções de espera std :: condition_variable não receberem um lock_guard, assim como um unique_lock, porque sempre que uma espera termina (por qualquer motivo), o mutex é readquirido automaticamente, de modo a não causar nenhuma violação semântica. No entanto, de acordo com o padrão, para usar um std :: lock_guard com uma variável de condição, é necessário usar um std :: condition_variable_any em vez de std :: condition_variable.

Edit : delete "Usando a interface pthreads, std :: condition_variable e std :: condition_variable_any devem ser idênticos". Ao analisar a implementação do gcc:

• std :: condition_variable :: wait (std :: unique_lock &) chama apenas pthread_cond_wait () na variável de condição pthread subjacente em relação ao mutex mantido por unique_lock (e, portanto, poderia fazer o mesmo com lock_guard, mas não o faz porque o padrão não prevê isso)
• std :: condition_variable_any pode trabalhar com qualquer objeto bloqueável, incluindo um que não seja um bloqueio mutex (portanto, pode até funcionar com um semáforo entre processos)