¿Ejemplo de boost shared_mutex (múltiples lecturas / una escritura)?

Tengo una aplicación multiproceso que tiene que leer algunos datos con frecuencia y, ocasionalmente, esos datos se actualizan. En este momento, un mutex mantiene el acceso a esos datos seguro, pero es caro porque me gustaría que varios subprocesos pudieran leer simultáneamente, y solo bloquearlos cuando se necesita una actualización (el subproceso de actualización podría esperar a que finalicen los otros subprocesos) .

Creo que esto es lo que boost::shared_mutexse supone que debe hacer, pero no tengo claro cómo usarlo y no he encontrado un ejemplo claro.

¿Alguien tiene un ejemplo simple que pueda usar para comenzar?

Parece que harías algo como esto:

boost::shared_mutex _access;
void reader()
{
  // get shared access
  boost::shared_lock<boost::shared_mutex> lock(_access);

  // now we have shared access
}

void writer()
{
  // get upgradable access
  boost::upgrade_lock<boost::shared_mutex> lock(_access);

  // get exclusive access
  boost::upgrade_to_unique_lock<boost::shared_mutex> uniqueLock(lock);
  // now we have exclusive access
}

1800 INFORMACIÓN es más o menos correcta, pero hay algunos problemas que quería corregir.

boost::shared_mutex _access;
void reader()
{
  boost::shared_lock< boost::shared_mutex > lock(_access);
  // do work here, without anyone having exclusive access
}

void conditional_writer()
{
  boost::upgrade_lock< boost::shared_mutex > lock(_access);
  // do work here, without anyone having exclusive access

  if (something) {
    boost::upgrade_to_unique_lock< boost::shared_mutex > uniqueLock(lock);
    // do work here, but now you have exclusive access
  }

  // do more work here, without anyone having exclusive access
}

void unconditional_writer()
{
  boost::unique_lock< boost::shared_mutex > lock(_access);
  // do work here, with exclusive access
}

También tenga en cuenta que, a diferencia de un shared_lock, solo un hilo puede adquirir un upgrade_lock a la vez, incluso cuando no está actualizado (lo que pensé que era incómodo cuando lo encontré). Entonces, si todos sus lectores son escritores condicionales, debe encontrar otra solución.

Desde C ++ 17 (VS2015) puede utilizar el estándar para bloqueos de lectura y escritura:

#include <shared_mutex>

typedef std::shared_mutex Lock;
typedef std::unique_lock< Lock > WriteLock;
typedef std::shared_lock< Lock > ReadLock;

Lock myLock;


void ReadFunction()
{
    ReadLock r_lock(myLock);
    //Do reader stuff
}

void WriteFunction()
{
     WriteLock w_lock(myLock);
     //Do writer stuff
}

Para la versión anterior, puede usar boost con la misma sintaxis:

#include <boost/thread/locks.hpp>
#include <boost/thread/shared_mutex.hpp>

typedef boost::shared_mutex Lock;
typedef boost::unique_lock< Lock >  WriteLock;
typedef boost::shared_lock< Lock >  ReadLock;

Solo para agregar más información empírica, he estado investigando todo el problema de los bloqueos actualizables y ¿ Ejemplo para boost shared_mutex (múltiples lecturas / una escritura)? es una buena respuesta agregando la información importante de que solo un hilo puede tener un bloqueo de actualización incluso si no está actualizado, eso es importante ya que significa que no puede actualizar de un bloqueo compartido a un bloqueo único sin liberar primero el bloqueo compartido. (Esto se ha discutido en otra parte, pero el hilo más interesante está aquí http://thread.gmane.org/gmane.comp.lib.boost.devel/214394 )

Sin embargo, encontré una diferencia importante (no documentada) entre un hilo esperando una actualización a un bloqueo (es decir, necesita esperar a que todos los lectores liberen el bloqueo compartido) y un bloqueo de escritor esperando lo mismo (es decir, un bloqueo único).

1. El hilo que está esperando un unique_lock en shared_mutex bloquea los nuevos lectores que ingresan, tienen que esperar la solicitud de los escritores. Esto asegura que los lectores no mueran de hambre a los escritores (sin embargo, creo que los escritores pueden matar de hambre a los lectores).

2. El hilo que está esperando a que se actualice un upgradeable_lock permite que otros hilos obtengan un bloqueo compartido, por lo que este hilo podría quedar muerto si los lectores son muy frecuentes.

Este es un tema importante a considerar y probablemente debería documentarse.

Utilice un semáforo con un recuento igual al número de lectores. Deje que cada lector cuente un semáforo para leer, de esa manera todos pueden leer al mismo tiempo. Luego deje que el escritor tome TODOS los recuentos de semáforos antes de escribir. Esto hace que el escritor espere a que finalicen todas las lecturas y luego bloquee las lecturas mientras escribe.

Gran respuesta de Jim Morris, me topé con esto y me tomó un tiempo darme cuenta. Aquí hay un código simple que muestra que después de enviar una "solicitud" para un boost de unique_lock (versión 1.54) se bloquean todas las solicitudes de shared_lock. Esto es muy interesante ya que me parece que elegir entre unique_lock y upgradeable_lock permite si queremos prioridad de escritura o no.

También (1) en la publicación de Jim Morris parece contradecir esto: Boost shared_lock. Leer preferido?

#include <iostream>
#include <boost/thread.hpp>

using namespace std;

typedef boost::shared_mutex Lock;
typedef boost::unique_lock< Lock > UniqueLock;
typedef boost::shared_lock< Lock > SharedLock;

Lock tempLock;

void main2() {
    cout << "10" << endl;
    UniqueLock lock2(tempLock); // (2) queue for a unique lock
    cout << "11" << endl;
    boost::this_thread::sleep(boost::posix_time::seconds(1));
    lock2.unlock();
}

void main() {
    cout << "1" << endl;
    SharedLock lock1(tempLock); // (1) aquire a shared lock
    cout << "2" << endl;
    boost::thread tempThread(main2);
    cout << "3" << endl;
    boost::this_thread::sleep(boost::posix_time::seconds(3));
    cout << "4" << endl;
    SharedLock lock3(tempLock); // (3) try getting antoher shared lock, deadlock here
    cout << "5" << endl;
    lock1.unlock();
    lock3.unlock();
}