boost::interprocess, прочитать, записать, прочитать Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Древовидный Переключить на: Стандартный Переключить на: Линейный

[alexy]

У меня экземпляры одного класса относяться к разным потокам и синхронизируются с помощью сигналов. для доступа к общим данным использую 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 блокировку.

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

Сообщение отредактировал alexy - 14.10.2013, 22:30

[Алексей1153]

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

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

или по такой

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

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

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

[alexy]

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

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

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

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

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