форсировать интерпроцессу manage_mapped_file найти ошибку

Я пытаюсь разделить структуру между процессами, используя интерпроцесс в Boost.

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

У меня проблемы с поиском объектов.

У меня есть следующее объявление:

typedef boost::interprocess::basic_managed_mapped_file
    < char,
    boost::interprocess::rbtree_best_fit<boost::interprocess::null_mutex_family,boost::interprocess::offset_ptr<void>>,
    boost::interprocess::flat_map_index>
    my_mapped_file;

В процессе А я делаю:

m_managedMappedFile.reset(new my_mapped_file(bip::open_or_create, filename, filesize));
auto hdr = m_managedMappedFile->find_or_construct<Foo>(bip::unique_instance)();
auto x = m_managedMappedFile->find<Foo>(bip::unique_instance);

Что работает, как я и ожидал, то есть находит объект. Теперь в процессе B:

    m_managedMappedFile.reset(new my_mapped_file(bip::open_only, filename));
    auto ret = m_managedMappedFile->find<Foo>(bip::unique_instance);

По какой-то причине метод find возвращает null в процессе B. Я понимаю, что делаю что-то глупое, но не могу понять.

Кто-нибудь может помочь?


c++ boost boost-interprocess
person Dave F    schedule 09.02.2015    source источник
comment
Как вы блокируете/синхронизируете? Потому что ты лучше знаешь, что делаешь. Мне никогда не приходилось обходить блокировку на уровне managed_mapped_file   -  person sehe    schedule 09.02.2015
comment
@sehe Если бы я не использовал нулевой мьютекс, я бы просто не смог заставить его работать; выполнение find_or_construct‹Foo›(unique_instance)() работает, но затем find‹Foo›(unique_instance) в другом процессе он будет зависать в ожидании мьютекса (в priv_generic_find), даже если процесс A был завершен!   -  person Dave F    schedule 09.02.2015
comment
Какая платформа, версии библиотек/компиляторов?   -  person sehe    schedule 09.02.2015
comment
Это была проблема - см. принятый ответ ниже   -  person Dave F    schedule 09.02.2015

Ответы (1)


arrow_upward
1
arrow_downward

Вам не нужно обходить механизм блокировки индексов bip::managed_mapped_file по умолчанию.

Посмотрите, сможете ли вы успешно запустить следующее:

#include <iostream>
#include <boost/interprocess/managed_mapped_file.hpp>

namespace bip = boost::interprocess;

struct X {
    int i;
};

int main()
{
    {
        bip::managed_mapped_file f(bip::open_or_create, "/tmp/mmf.bin", 1ul << 20);

        if (!f.find<X>(bip::unique_instance).first) {
            auto xp = f.find_or_construct<X>(bip::unique_instance)();

            assert(xp);
            xp->i = 42;
        }
    }

    {
        bip::managed_mapped_file f(bip::open_only, "/tmp/mmf.bin");
        auto xp = f.find<X>(bip::unique_instance).first;

        if (xp)
            std::cout << "value: " << xp->i++ << "\n";
    }
}

Это должно печатать 42 при первом запуске (или после того, как файл был воссоздан) и увеличивать числа при каждом последующем запуске.

Я собираюсь взглянуть на реализацию unique_instance_t* перегрузок менеджеров сегментов, но я подозреваю, что они могут не работать, потому что политика мьютекса была обнулена. Хотя на данный момент это всего лишь догадка.

Я бы сосредоточился на выяснении того, почему вы не можете заставить Interprocess managed_mapped_file работать в конфигурации по умолчанию, на вашей платформе и при установке.

person sehe    schedule 09.02.2015
comment
Большое спасибо за вашу помощь - я как раз собирал для вас версии компилятора/библиотеки, и я понял, что мое основное приложение было 64-битным, а мое тестовое приложение было 32-битным - это (по понятным причинам) сбивало с толку. Еще раз спасибо! - person Dave F; 09.02.2015
comment
Это действительно имеет смысл, поскольку похоже, что, по крайней мере, здесь метод unique_instance_t использует typeid(T).name(), который будет другим :) - person sehe; 09.02.2015
comment
(На самом деле, ударьте по этому. Совместное использование классов C++ между процессами с разными ABI будет просто Undefined Behavior. Я не думаю, что Boost Interprocess обнаруживает это и избегает этого) - person sehe; 09.02.2015