Esempio per boost shared_mutex (più letture / una scrittura)?

Ho un'app multithread che deve leggere spesso alcuni dati e occasionalmente tali dati vengono aggiornati. In questo momento un mutex mantiene l'accesso a quei dati al sicuro, ma è costoso perché vorrei che più thread fossero in grado di leggere contemporaneamente e bloccarli solo quando è necessario un aggiornamento (il thread di aggiornamento potrebbe attendere che gli altri thread finiscano) .

Penso che questo sia ciò che boost::shared_mutexdovrebbe fare, ma non sono chiaro su come usarlo e non ho trovato un esempio chiaro.

Qualcuno ha un semplice esempio che potrei usare per iniziare?

Sembra che faresti qualcosa del genere:

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 INFORMAZIONI è più o meno corretto, ma ci sono alcuni problemi che volevo correggere.

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
}

Nota inoltre, a differenza di shared_lock, solo un singolo thread può acquisire un upgrade_lock in una sola volta, anche quando non è aggiornato (cosa che ho pensato fosse imbarazzante quando mi sono imbattuto in esso). Quindi, se tutti i tuoi lettori sono scrittori condizionali, devi trovare un'altra soluzione.

A partire da C ++ 17 (VS2015) è possibile utilizzare lo standard per i blocchi di lettura-scrittura:

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

Per la versione precedente, puoi utilizzare boost con la stessa sintassi:

#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 per aggiungere alcune informazioni più empiriche, ho indagato sull'intero problema dei blocchi aggiornabili e Esempio per boost shared_mutex (più letture / una scrittura)? è una buona risposta aggiungendo le informazioni importanti che solo un thread può avere un upgrade_lock anche se non è aggiornato, che è importante in quanto significa che non è possibile aggiornare da un blocco condiviso a un blocco univoco senza rilasciare prima il blocco condiviso. (Questo è stato discusso altrove, ma il thread più interessante è qui http://thread.gmane.org/gmane.comp.lib.boost.devel/214394 )

Tuttavia ho trovato un'importante differenza (non documentata) tra un thread in attesa di un aggiornamento a un blocco (cioè deve attendere che tutti i lettori rilascino il blocco condiviso) e un blocco del writer in attesa della stessa cosa (cioè un unique_lock).

1. Il thread in attesa di un unique_lock su shared_mutex blocca eventuali nuovi lettori in arrivo, devono attendere la richiesta dei writer. Ciò garantisce che i lettori non muoiano di fame gli scrittori (tuttavia credo che gli scrittori potrebbero far morire di fame i lettori).

2. Il thread in attesa dell'aggiornamento di un upgradeeable_lock consente ad altri thread di ottenere un blocco condiviso, quindi questo thread potrebbe essere affamato se i lettori sono molto frequenti.

Questa è una questione importante da considerare e probabilmente dovrebbe essere documentata.

Utilizza un semaforo con un conteggio uguale al numero di lettori. Lascia che ogni lettore prenda un conteggio del semaforo per leggere, in questo modo possono leggere tutti allo stesso tempo. Quindi lascia che lo scrittore prenda TUTTI i conteggi dei semafori prima di scrivere. Ciò fa sì che il writer attenda il completamento di tutte le letture e quindi blocchi le letture durante la scrittura.

Grande risposta di Jim Morris, mi sono imbattuto in questo e mi ci è voluto un po 'per capire. Ecco un semplice codice che mostra che dopo aver inviato una "richiesta" per un unique_lock boost (versione 1.54) blocca tutte le richieste shared_lock. Questo è molto interessante in quanto mi sembra che scegliere tra unique_lock e upgradeable_lock consenta se vogliamo priorità di scrittura o nessuna priorità.

Anche (1) nel post di Jim Morris sembra contraddire questo: Boost shared_lock. Leggere preferito?

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