crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

 
Ответить в данную темуНачать новую тему
> boost::interprocess, прочитать, записать, прочитать
alexy
  опции профиля:
сообщение 14.10.2013, 22:22
Сообщение #1


Студент
*

Группа: Участник
Сообщений: 44
Регистрация: 4.8.2010
Пользователь №: 1931

Спасибо сказали: 0 раз(а)




Репутация:   0  


У меня экземпляры одного класса относяться к разным потокам и синхронизируются с помощью сигналов. для доступа к общим данным использую 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
  опции профиля:
сообщение 15.10.2013, 6:58
Сообщение #2


фрилансер
******

Группа: Участник
Сообщений: 2885
Регистрация: 19.6.2010
Из: Обливион
Пользователь №: 1822

Спасибо сказали: 215 раз(а)




Репутация:   34  


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


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

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

mutex.lock()
   быстро читаем, удостоверяемся, что данные ещё актуальны
   пишем
   сигналим
mutex.unlock()
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Iron Bug
  опции профиля:
сообщение 15.10.2013, 7:40
Сообщение #3


Профессионал
*****

Группа: Модератор
Сообщений: 1587
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 218 раз(а)




Репутация:   12  


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

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

#include <boost/thread.hpp>

using namespace boost;

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

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

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

это общий принцип работы с бустовскими мьютексами. вообще, про мьютексы и синхронизацию читать тут.

общее описание различных видов lock'ов детально объяснено в Lock concepts

Сообщение отредактировал Iron Bug - 15.10.2013, 7:48
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
alexy
  опции профиля:
сообщение 15.10.2013, 11:29
Сообщение #4


Студент
*

Группа: Участник
Сообщений: 44
Регистрация: 4.8.2010
Пользователь №: 1931

Спасибо сказали: 0 раз(а)




Репутация:   0  


Цитата(Алексей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
Сообщение #5


Профессионал
*****

Группа: Модератор
Сообщений: 1587
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 218 раз(а)




Репутация:   12  


interprocess - это межпроцессное взаимодействие. внутри одного приложения его применять можно, но совершенно бессмысленно. разве что для передачи каких-то статических данных между запусками приложения, и то с натяжкой. дело в том, что interprocess сохраняет состояние: то есть, в файловой системе (глобально) создаются файлы, которые затем используются всеми процессами одного пользователя. он задействует очень много ресурсов и не так быстр, как работа внутри одного процесса.
вообще, у буста есть принципы, по которым строится работа средств синхронизации - concepts. они описаны в документации. а сами мьютексы, как объекты, которыми оперируют локи, определены в разных библиотеках и работают в разных пространствах памяти, в зависимости от библиотеки.
принципы для мьютексов описаны здесь: Mutex Concepts. есть разные мьютексы и разный подход к залочиванию данных. далее, выбор делается из того, что тебе нужно.

Сообщение отредактировал Iron Bug - 15.10.2013, 11:51
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
alexy
  опции профиля:
сообщение 16.10.2013, 12:12
Сообщение #6


Студент
*

Группа: Участник
Сообщений: 44
Регистрация: 4.8.2010
Пользователь №: 1931

Спасибо сказали: 0 раз(а)




Репутация:   0  


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

Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 18.8.2019, 7:48