boost::interprocess, Я мало травы выкурил чтобы это понять? Опции

[alexy]

Создаю я значит класс, который можно вызывать из разных процессов, типа

using namespace boost::interprocess;

class foo {
public:
  std::string bar()const{
     shared_lock<interprocess_upgradable_mutex> lock(mutex);
     // get the data;
     return data;
   }
  void bar(const std::string& nb){
     scoped_lock<interprocess_upgradable_mutex> lock(mutex);
     //write the data
  }

private:
  static interprocess_upgradable_mutex mutex;
};
// определяю mutex в cpp файле

У меня вываливается (еще до вызова конструктра, даже заблокировать-то еще не успел ничего)

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
  what():  boost::lock_error

Может я не правильно библиотеку использую?

[Iron Bug]

пример использования можно посмотреть тут, например:
http://stackoverflow.com/questions/1243909...lock-with-boost

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

вообще, boost::interprocess реализован через файлы и, фактически, такой элемент имеет "filesystem persistency" - хз, как по-русски это перевести, но смысл понятен, я думаю: пока явно его не убьёшь, он будет болтаться в виде файла (привязан к сессии юзера, на самом деле). так что там могут получаться эффекты от разных запусков: например, написал софтину, запустил - какой-то элемент остался в общем пространстве (буст ведь не знает, будут ли ещё процессы его использовать или нет, а чтобы его явно удалить, нужно вызывать статический remove). потом, например, ещё раз запустил софтину или поменял что-то и запустил - а "старый" объект-то так и висит в системе. поэтому когда с межпроцессными объектами работаешь - нужно много всякой дополнительной фигни учитывать, это немного сложнее, чем просто межпоточное взаимодействие, потому что всё глобально на уровне системы. иногда бывает, что от старых неудачных запусков осталась какая-то хрень в виде лока, например, и второй раз он его залочить не даст. или что-то подобное. в общем, там могут оказаться довольно неожиданные ситуации, хотя они возникают довольно редко.
чтобы просто убедиться, что это не такой глюк, можно найти хранилище этого самого interprocess'а (под вендой он его создаёт где-то на системном винте, в юзерском каталоге для временных файлов, а под линём - в tmp, если правильно помню, это надо в коде самого буста смотреть или поискать просто каталог с именем interprocess). и внутри него всё грохнуть (т.е. как бы почистить принудительно). а потом снова запустить софтину. если это глюк из-за "застрявших" объектов - ошибка исчезнет. но тут надо будет выяснять, а почему они, собственно, застряли. это уже вопрос реализации логики программы.

Сообщение отредактировал Iron Bug - 23.2.2013, 3:48