crossplatform.ru

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


  Ответ в boost::interprocess
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
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); // то есть подпищики могут читать..
} // и тут разумеется разблокируется :)

Iron Bug Дата 15.10.2013, 11:50
  interprocess - это межпроцессное взаимодействие. внутри одного приложения его применять можно, но совершенно бессмысленно. разве что для передачи каких-то статических данных между запусками приложения, и то с натяжкой. дело в том, что interprocess сохраняет состояние: то есть, в файловой системе (глобально) создаются файлы, которые затем используются всеми процессами одного пользователя. он задействует очень много ресурсов и не так быстр, как работа внутри одного процесса.
вообще, у буста есть принципы, по которым строится работа средств синхронизации - concepts. они описаны в документации. а сами мьютексы, как объекты, которыми оперируют локи, определены в разных библиотеках и работают в разных пространствах памяти, в зависимости от библиотеки.
принципы для мьютексов описаны здесь: Mutex 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, 7:40
  заметь, что interprocess - это не работа между потоками, это работа между процессами. это общая память между приложениями, в которой создаются мьютексы, буферы памяти для обмена и прочие общие объекты. а для синхронизации потоков внутри процесса используются обычные мьютексы boost::thread::mutex.

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

#include <boost/thread.hpp>

using namespace boost;

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

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

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

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

общее описание различных видов lock'ов детально объяснено в Lock concepts
Алексей1153 Дата 15.10.2013, 6:58
  обычно это по такой схеме делается (не про буст речь, а вообще)
mutex.lock()
   читаем
   пишем
   сигналим
mutex.unlock()


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

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

mutex.lock()
   быстро читаем, удостоверяемся, что данные ещё актуальны
   пишем
   сигналим
mutex.unlock()
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 блокировку.

что можно использовать для такой задачи?
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 16.4.2024, 18:25