Проблема с удалением boost::interprocess::named_mutex

Я сделал программу ниже, но в конце не удалось удалить named_mutex, распечатайте результат «Ошибка удаления мьютекса»

void IPC::testNamedMutex()
{
named_mutex mutex(open_or_create, "MyMutex");
for (int i = 0; i < 10; i++)
{
    mutex.lock();
    cout << "Mutex taken" << endl;

    std::fstream fs("test.txt", std::fstream::out | std::fstream::app);
    if (fs)
    {
        fs << "Thread id: " << boost::this_thread::get_id() << ", "
                << "Iteration " << i << endl;
    }

    boost::this_thread::sleep(boost::posix_time::seconds(1));
    mutex.unlock();
    cout << "Mutex is unlocked" << endl;

}
cout << "Delete the file and mutex?(y/n): ";
char c;
cin >> c;
if (c == 'y' || c == 'Y')
{
    if (remove("test.txt"))
        cout << "File deleted" << endl;
    else
        cout << "File delete failed" << endl;

    bool success=named_mutex::remove("MyMutex");
    if (success)
        cout << "Mutex removed" << endl;
    else
        cout << "Mutex delete failure" << endl;
}
}

Однако, если я запускаю удаление со второй программой, такой как ниже, она работает. Что может быть причиной?

void IPC::testDeleteNamedMutex()
{
cout << named_mutex::remove("MyMutex") << endl;
}

person Michael    schedule 04.02.2014    source источник


Ответы (1)


Насколько я знаю, это происходит в Windows, если мьютекс был создан во время работы в контексте с повышенными правами, но вы пытаетесь удалить его как обычный пользователь.

Другими словами, UAC снова все портит.

Теоретически вы должны иметь возможность настроить ACL (списки контроля доступа) для предоставления разрешений предполагаемым пользователям/группам. Я не пробовал это. Я бы проконсультировался с Technet и/или вашими местными администраторами, чтобы узнать больше, если вам нужно.

person sehe    schedule 04.02.2014
comment
Спасибо. Я работаю в unbuntu 12.04 с gcc4.8.1 в режиме отладки. - person Michael; 04.02.2014
comment
Я бы все еще исследовал возможные проблемы с разрешениями. Попробуйте chown -Rc $UID /dev/shm и/или lsof +D /dev/shm/, чтобы обнаружить любые нарушения совместного доступа - person sehe; 04.02.2014