Robust mutex in shared memory not so robust

Question

When using a pthread-based robust mutex via boost::interprocesss::managed_shared_memory object to signal from one process to another, I notice there are issues: a) depending on start-up order and/or b) a change in behaviour when processes are restarted. The crux of the problem is that under certain conditions, the signals (via condition variables) in my sample apps are not received.

I have published a (minimal) code sample in git - https://github.com/zerodefect/mutex_example . I have tried to keep the code sample as brief as possible, but it still spans a few files. I'm hoping it is acceptable to link to a repository in GitHub in this instance?

I have 2 processes - process_b:

while (true)
{
    // Notify 'Process A' every 2 seconds.
    std::this_thread::sleep_for(std::chrono::seconds(2));
    pthread_cond_signal(pCv);

    std::cout << "Info: Signaled" << std::endl;
}

which merely attempts to signal to process_a:

while (true)
{
    if (!timed_lock_mutex(pMutex, std::chrono::seconds(5)))
    {
        std::cout << "Warning: Mutex wait timeout." << std::endl;
        continue;
    }

    BOOST_SCOPE_EXIT(pMutex)
    {
        unlock_mutex(pMutex);
    } BOOST_SCOPE_EXIT_END

    if (!wait_for_cv(pCv, pMutex, std::chrono::seconds(10)))
    {
        std::cout << "Warning: Wait timeout!" << std::endl;
        continue;
    }

    std::cout << "Info: Received notification." << std::endl;
}

Problem Scenarios

Scenario 1:

1. Start process A
2. Start process B (signals not received)

Scenario 2:

1. Start process B
2. Start process A (works at this point)
3. Restart process B (signals stop being received)

Questions:

1. Am I using boost's managed_shared_memory object correctly?
2. Have I configured the mutex correctly?

Environment:

• Linux via Ubuntu 18.04.3 LTS
• GCC v8.3.0
• Boost v1.55

Update: @Jorge Bellon identified an issue where the mutex/condition_variable were being initialized twice. After being resolved, the program now seizes in the CV When it locks up, the stack traces appear as:

process_a:

futex_wait 0x00007ffff7bc3602
futex_wait_simple 0x00007ffff7bc3602
__condvar_acquire_lock 0x00007ffff7bc3602
__condvar_cancel_waiting 0x00007ffff7bc3602
__pthread_cond_wait_common 0x00007ffff7bc40bd
__pthread_cond_timedwait 0x00007ffff7bc40bd
wait_until cv_utils.cpp:73
wait_for_cv cv_utils.cpp:93
main main_process_a.cpp:85
__libc_start_main 0x00007ffff6fe6b97
_start 0x000055555555734a

process_b:

futex_wait 0x00007ffff7bc44b0
futex_wait_simple 0x00007ffff7bc44b0
__condvar_quiesce_and_switch_g1 0x00007ffff7bc44b0
__pthread_cond_signal 0x00007ffff7bc44b0
main main_process_b.cpp:73
__libc_start_main 0x00007ffff6fe6b97
_start 0x00005555555573aa

Answer 1

My guess is your code locks because you never destroy shared memory https://theboostcpplibraries.com/boost.interprocess-shared-memory

If remove() is never called, the shared memory continues to exist even if the program terminates. Whether or not the shared memory is automatically deleted depends on the underlying operating system. Windows and many Unix operating systems, including Linux, automatically delete shared memory once the system is restarted.

Thus Process A try to acquire a lock of condvar internal mutex in pthread_cond_wait call, but it is already locked in previous runs. And because you have no exit logic, you most definitely killed processes, thus never releasing the lock. Same goes for Process B.

The fact that the mutex your've created is a robust mutex is irrelevant. Because it is not it you are locked waiting for. ...But I'm actually not sure what are you waiting for. Not sure what are properties of condvar internal futex. Further investigation is needed. But judging by the observed behavior it is not robust.

And by the way, you get but do not use shared mutex in Process B. But maybe, just maybe, you should Calling pthread_cond_signal without locking mutex And one more thing: pthread_cond_timedwait can return EOWNERDEAD and you must check for that error in your wait_for_cv()