Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Форум на CrossPlatform.RU _ boost _ boost::interprocess

Автор: alexy 14.10.2013, 22:22

У меня экземпляры одного класса относяться к разным потокам и синхронизируются с помощью сигналов. для доступа к общим данным использую boost::interprocess::upgradeable_mutex. сделал такие объявления

typedef boost::interprocess::interprocess_upgradable_mutex mutex_type;
typedef boost::interprocess::scoped_lock<mutex_type>       scoped_lock;
typedef boost::interprocess::sharable_lock<mutex_type>     sharable_lock;
typedef boost::interprocess::upgradable_lock<mutex_type>   upgradeable_lock;

когда метод только пишет или читает, то понятно. некоторым методам надо сначала найти инфу, потом записать, а потом просигналить что они изменили её. сейчас я как бы терю блокировку - то есть снчала прочитал данные, потом записал, потом опять прочитал. а нужно чтобы в это время блокировка не терялась, т.к. данные могут уже измениться, после того как я их прочитал..
где-то нашел это в интернете boost::upgrade_to_unique_lock но в бусте его не нашел

то есть я думал, что создам переменную, которая переведет муткс в эксклюзивную блокировку, потом, при удалении, вернет в upgradeable блокировку.

что можно использовать для такой задачи?

Автор: Алексей1153 15.10.2013, 6:58

обычно это по такой схеме делается (не про буст речь, а вообще)

mutex.lock()
   читаем
   пишем
   сигналим
mutex.unlock()

или по такой

mutex.lock()
   быстро читаем 
mutex.unlock()

долго анализируем

mutex.lock()
   быстро читаем, удостоверяемся, что данные ещё актуальны
   пишем
   сигналим
mutex.unlock()

Автор: Iron Bug 15.10.2013, 7:40

заметь, что interprocess - это не работа между потоками, это работа между процессами. это общая память между приложениями, в которой создаются мьютексы, буферы памяти для обмена и прочие общие объекты. а для синхронизации потоков внутри процесса используются обычные мьютексы boost::thread::mutex.

с областями видимости ("создали переменную - заблокировано") работают scoped мьютексы.
на практике это выглядит так:

#include <boost/thread.hpp>

using namespace boost;

// где-то снаружи обоих потоков объявлен мьютекс
mutex some_mutex;
...

{
// некая область видимости
...
// здесь мьютекс не объявлен и не залочен
...
mutex::scoped_lock lock(some_mutex); 
// здесь мьютекс залочен
}

// здесь (снаружи области видимости) мьютекс сброшен

это общий принцип работы с бустовскими мьютексами. вообще, http://www.boost.org/doc/libs/1_53_0/doc/html/thread/synchronization.html.

общее описание различных видов lock'ов детально объяснено в http://www.boost.org/doc/libs/1_53_0/doc/html/thread/synchronization.html#thread.synchronization.lock_concepts

Автор: alexy 15.10.2013, 11:29

Цитата(Алексей1153 @ 15.10.2013, 7:58)

обычно это по такой схеме делается (не про буст речь, а вообще)

mutex.lock()
   читаем
   пишем
   сигналим
mutex.unlock()

это была моя первая идея, так не выйдет. просто на сигналы подписываются еще куча классов. они должны использовать интерфейс для доступа к данным. интерфейс, чтобы получить доступ, использует shared_lock. то есть в ответ на сигнал получиться дедлок. или нужно переделывать public методы класса разделяя их на потокобезопасные и без блокировок. что не есть гуд я думаю. поэтому и хотел чтобы блокировки менялись в писателе.

IronBug, спасибо прочитаю.. то есть если мне только внутри одного приложения нужна сингхронизация, то лучше thread::mutex использовать, да?

All, кстати, насколько я понял в interprocess используют функцию boost::move чтобы поменять блокировки, так? но её нужно несколько раз вызывать чтобы реализовать эту задачу. я надеялся что есть какой-то "выделение ресурса есть инициализация".

Автор: Iron Bug 15.10.2013, 11:50

interprocess - это межпроцессное взаимодействие. внутри одного приложения его применять можно, но совершенно бессмысленно. разве что для передачи каких-то статических данных между запусками приложения, и то с натяжкой. дело в том, что interprocess сохраняет состояние: то есть, в файловой системе (глобально) создаются файлы, которые затем используются всеми процессами одного пользователя. он задействует очень много ресурсов и не так быстр, как работа внутри одного процесса.
вообще, у буста есть принципы, по которым строится работа средств синхронизации - concepts. они описаны в документации. а сами мьютексы, как объекты, которыми оперируют локи, определены в разных библиотеках и работают в разных пространствах памяти, в зависимости от библиотеки.
принципы для мьютексов описаны здесь: http://www.boost.org/doc/libs/1_53_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts. есть разные мьютексы и разный подход к залочиванию данных. далее, выбор делается из того, что тебе нужно.

Автор: alexy 16.10.2013, 12:12

Отлично, сделал, спасибо ( после RTFM )
короче сейчас так.

void some_fnc(const int& par) {
   // проверки всякие
   upgrade_lock lock(mutex);
   // тут поиск и приготовления
   {
      upgrade_to_unique_lock slock(lock);
      // тут запись
   } // здесь блокировака становиться снова upgradeable
   foo_sign(par); // то есть подпищики могут читать..
} // и тут разумеется разблокируется :)