Przykład dla boost shared_mutex (wiele odczytów / jeden zapis)?

Mam aplikację wielowątkową, która musi często czytać niektóre dane, a czasami te dane są aktualizowane. W tej chwili mutex zapewnia bezpieczny dostęp do tych danych, ale jest drogi, ponieważ chciałbym, aby wiele wątków mogło czytać jednocześnie i blokować je tylko wtedy, gdy potrzebna jest aktualizacja (wątek aktualizacji może czekać na zakończenie innych wątków) .

Myślę, że to właśnie boost::shared_mutexpowinno zrobić, ale nie jestem pewien, jak go używać, i nie znalazłem jasnego przykładu.

Czy ktoś ma prosty przykład, którego mógłbym użyć, aby rozpocząć?

Wygląda na to, że zrobiłbyś coś takiego:

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 INFORMACJE jest mniej więcej poprawne, ale jest kilka problemów, które chciałem poprawić.

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
}

Zauważ również, że w przeciwieństwie do shared_lock, tylko jeden wątek może uzyskać upgrade_lock w jednym czasie, nawet jeśli nie jest zaktualizowany (co uważałem za niezręczne, kiedy na to wpadłem). Tak więc, jeśli wszyscy twoi czytelnicy są pisarzami warunkowymi, musisz znaleźć inne rozwiązanie.

Od C ++ 17 (VS2015) możesz używać standardu blokad do odczytu i zapisu:

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

W przypadku starszej wersji możesz użyć funkcji boost z tą samą składnią:

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

Aby dodać więcej informacji empirycznych, badałem cały problem blokad z możliwością aktualizacji i przykład dla zwiększenia shared_mutex (wiele odczytów / jeden zapis)? jest dobrą odpowiedzią, dodając ważne informacje, że tylko jeden wątek może mieć upgrade_lock, nawet jeśli nie jest zaktualizowany, co jest ważne, ponieważ oznacza to, że nie można zaktualizować wspólnej blokady do unikalnej blokady bez uprzedniego zwolnienia wspólnej blokady. (Zostało to omówione w innym miejscu, ale najciekawszy wątek jest tutaj http://thread.gmane.org/gmane.comp.lib.boost.devel/214394 )

Jednak znalazłem ważną (nieudokumentowaną) różnicę między wątkiem oczekującym na aktualizację do blokady (tj. Musi czekać, aż wszyscy czytelnicy zwolnią współdzieloną blokadę) a blokadą pisarza czekającą na to samo (tj. Unique_lock).

1. Wątek, który czeka na unique_lock na shared_mutex, blokuje przychodzących nowych czytelników, muszą oni czekać na żądanie pisarzy. Gwarantuje to, że czytelnicy nie głodują pisarzy (jednak uważam, że pisarze mogą głodować czytelników).

2. Wątek, który czeka na aktualizację upgradeable_lock, pozwala innym wątkom uzyskać współdzieloną blokadę, więc ten wątek może zostać zagłodzony, jeśli czytelnicy będą bardzo często.

Jest to ważna kwestia do rozważenia i prawdopodobnie powinna zostać udokumentowana.

Użyj semafora z liczbą równą liczbie czytelników. Niech każdy czytelnik policzy semafor po jednym policzeniu, aby móc czytać, tak aby wszyscy mogli czytać w tym samym czasie. Następnie pozwól pisarzowi wziąć WSZYSTKIE liczby semaforów przed napisaniem. Powoduje to, że piszący czeka na zakończenie wszystkich odczytów, a następnie blokuje odczyty podczas pisania.

Świetna odpowiedź Jima Morrisa. Natknąłem się na to i zajęło mi trochę czasu, zanim zrozumiałem. Oto prosty kod, który pokazuje, że po przesłaniu „żądania” wzmocnienia unique_lock (wersja 1.54) wszystkie żądania shared_lock zostaną zablokowane. Jest to bardzo interesujące, ponieważ wydaje mi się, że wybór między unique_lock i upgradeable_lock pozwala na to, czy chcemy pisać priorytet, czy nie.

Również (1) w poście Jima Morrisa wydaje się temu zaprzeczać: Boost shared_lock. Czytaj preferowane?

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