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

Tengo dos casos de uso.

A. Quiero sincronizar el acceso de dos hilos a una cola.

B. Quiero sincronizar el acceso de dos subprocesos a una cola y usar una variable de condición porque uno de los subprocesos esperará que el otro subproceso almacene contenido en la cola.

Para el caso de uso AI vea el ejemplo de código usando std::lock_guard<>. Para el caso de uso BI, vea el ejemplo de código usando std::unique_lock<>.

¿Cuál es la diferencia entre los dos y cuál debo usar en qué caso de uso?

La diferencia es que puedes bloquear y desbloquear a std::unique_lock. std::lock_guardserá bloqueado solo una vez en construcción y desbloqueado en destrucción.

Entonces, para el caso de uso B, definitivamente necesita un std::unique_lockpara la variable de condición. En el caso A, depende de si necesita volver a bloquear la guardia.

std::unique_locktiene otras características que le permiten, por ejemplo: construirse sin bloquear el mutex inmediatamente, pero construir el contenedor RAII (ver aquí ).

std::lock_guardtambién proporciona un conveniente contenedor RAII, pero no puede bloquear múltiples mutexes de manera segura. Se puede usar cuando necesita un contenedor para un alcance limitado, por ejemplo: una función miembro:

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 aclarar una pregunta por chmike, por defecto std::lock_guardy std::unique_lockson lo mismo. Entonces, en el caso anterior, podría reemplazar std::lock_guardcon std::unique_lock. Sin embargo, std::unique_lockpodría tener un poco más de gastos generales.

Tenga en cuenta que en estos días se debe usar en std::scoped_locklugar de std::lock_guard.

lock_guardy unique_lockson más o menos lo mismo; lock_guardes una versión restringida con una interfaz limitada.

A lock_guardsiempre tiene un candado desde su construcción hasta su destrucción. A unique_lockse puede crear sin bloqueo inmediato, se puede desbloquear en cualquier momento de su existencia y se puede transferir la propiedad del bloqueo de una instancia a otra.

Por lo tanto, siempre usa lock_guard, a menos que necesite las capacidades de unique_lock. A condition_variablenecesita a unique_lock.

Úselo a lock_guardmenos que necesite poder unlockactivar manualmente el mutex sin destruir el lock.

En particular, condition_variabledesbloquea su exclusión mutua cuando se va a dormir a las llamadas a wait. Es por eso que a lock_guardno es suficiente aquí.

Hay ciertas cosas comunes entre lock_guardy unique_locky ciertas diferencias.

Pero en el contexto de la pregunta formulada, el compilador no permite el uso de una lock_guardcombinación en combinación con una variable de condición, porque cuando un subproceso llama a esperar en una variable de condición, el mutex se desbloquea automáticamente y cuando otros subprocesos / subprocesos notifican y el subproceso actual se invoca (sale de la espera), el bloqueo se vuelve a adquirir.

Este fenómeno es contrario al principio de lock_guard. lock_guardpuede construirse solo una vez y destruirse solo una vez.

Por lock_guardlo tanto , no se puede usar en combinación con una variable de condición, pero sí unique_lockse puede (porque unique_lockse puede bloquear y desbloquear varias veces).

En realidad no son los mismos mutexes, lock_guard<muType>tiene casi lo mismo que std::mutex, con la diferencia de que su vida útil termina al final del alcance (llamado D-tor), por lo que una definición clara sobre estos dos mutexes:

lock_guard<muType> tiene un mecanismo para poseer un mutex por la duración de un bloque de ámbito.

Y

unique_lock<muType> es un contenedor que permite el bloqueo diferido, los intentos de bloqueo de tiempo limitado, el bloqueo recursivo, la transferencia de la propiedad del bloqueo y el uso con variables de condición.

Aquí hay un ejemplo de implementación:

#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;
}

En este ejemplo, usé el unique_lock<muType>concondition variable

Como se ha mencionado por otros, std :: unique_lock rastrea el estado bloqueado del mutex, por lo que puede diferir el bloqueo hasta después de la construcción del bloqueo y desbloquearlo antes de la destrucción del bloqueo. std :: lock_guard no permite esto.

Parece que no hay ninguna razón por la cual las funciones de espera std :: condition_variable no deberían tomar un lock_guard y un unique_lock, porque cada vez que finaliza una espera (por cualquier razón), el mutex se vuelve a adquirir automáticamente para que no cause ninguna violación semántica. Sin embargo, según el estándar, para usar std :: lock_guard con una variable de condición, debe usar std :: condition_variable_any en lugar de std :: condition_variable.

Editar : eliminado "El uso de la interfaz pthreads std :: condition_variable y std :: condition_variable_any debería ser idéntico". Al observar la implementación de gcc:

• std :: condition_variable :: wait (std :: unique_lock &) solo llama a pthread_cond_wait () en la variable de condición pthread subyacente con respecto a la exclusión mutua mantenida por unique_lock (y podría igualmente hacer lo mismo para lock_guard, pero no lo hace porque el estándar no prevé eso)
• std :: condition_variable_any puede funcionar con cualquier objeto bloqueable, incluido uno que no sea un bloqueo mutex (por lo tanto, incluso podría funcionar con un semáforo entre procesos)