Приклад boost shared_mutex (кілька читання / одна запис)?

У мене є багатопотокова програма, якій доводиться часто читати деякі дані, а періодично ці дані оновлюються. Зараз mutex зберігає доступ до цих даних безпечним, але це дорого, тому що я хотів би, щоб декілька потоків могли читати одночасно, і блокувати їх лише тоді, коли потрібно оновлення (оновлення потоку може чекати, коли інші потоки завершаться) .

Я думаю, що boost::shared_mutexце має робити, але мені не ясно, як це використовувати, і я не знайшов чіткого прикладу.

Хтось має простий приклад, який я міг би використовувати для початку?

Схоже, ви зробили б щось подібне:

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 є більш-менш правильною, але є кілька питань, які я хотів виправити.

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
}

Також зауважте, на відміну від shared_lock, лише один потік може придбати оновлення_блок одночасно, навіть коли він не оновлений (що, на мою думку, було незручно, коли я натрапив на нього). Отже, якщо всі ваші читачі - це умовні письменники, вам потрібно знайти інше рішення.

Оскільки C ++ 17 (VS2015) ви можете використовувати стандарт для блокування читання-запису:

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

Для старшої версії можна використовувати boost з тим же синтаксисом:

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

Для того, щоб додати ще емпіричну інформацію, я досліджував всю проблему блоків, що можна оновити , та приклад для підвищення shared_mutex (кілька читань / один запис)? є гарною відповіддю, додаючи важливу інформацію про те, що лише один потік може мати оновлення_блоку, навіть якщо він не оновлений, що важливо, оскільки це означає, що ви не можете оновити зі спільного блокування до унікального блокування, не звільняючи спочатку загальний замок. (Це обговорювалося в іншому місці, але найцікавіша тема тут http://thread.gmane.org/gmane.comp.lib.boost.devel/214394 )

Однак я виявив важливу (незадокументовану) різницю між потоком, який чекає оновлення до блокування (тобто потрібно чекати, коли всі читачі вийдуть із загального блокування), і записом запису, який очікує тієї самої речі (тобто унікальний_блок).

1. Нитка, яка чекає унікального_блока на shared_mutex, блокує будь-які нові читачі, що надходять, їм доведеться чекати запиту авторів. Це гарантує, що читачі не голодують письменниками (однак, я вважаю, що письменники могли голодувати читачами).

2. Потік, який чекає на оновлення_lockable, дозволяє іншим потокам отримати загальний замок, тому ця нитка може бути голодованою, якщо читачі дуже часті.

Це важливе питання, яке слід врахувати, і, ймовірно, має бути задокументовано.

Скористайтеся семафором з кількістю, що дорівнює кількості читачів. Нехай кожен читач візьме один підрахунок семафору, щоб прочитати, щоб вони могли читати одночасно. Тоді дозвольте письменникові взяти ВСІ підрахунки семафору до написання. Це змушує письменника чекати, коли всі читання закінчать, а потім блокує читання під час написання.

Чудова реакція Джима Морріса, я натрапив на це, і мені знадобилося певний час. Ось простий код, який показує, що після надсилання "запиту" на унікальне збільшення_блокування (версія 1.54) блокує всі запити на спільний_блок. Це дуже цікаво, оскільки мені здається, що вибір між унікальним_блоком та оновленням_блоку дозволяє, якщо ми хочемо написати пріоритет або немає пріоритету.

Також (1) у публікації Джима Морріса, здається, суперечить цьому: Підвищити спільний_блок. Читати краще?

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