Re: [interprocess] Mutex and condition at process termination

From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2020-05-14 13:32:41

Em qui., 14 de mai. de 2020 Ã s 07:42, Phil Endecott via Boost <
boost_at_[hidden]> escreveu:

> * The system could be made more robust by blocking signals while
> a mutex is locked.  This doesn't help with crashes, e.g. segfaults,
> but it would help with ctrl-C.
>

I don't think this is a good idea. Signals are a property of the
application and libraries rarely should touch signals silently. Blocking
signals (instead handling them) is better, but it shouldn't happen across
the return of some function without a good excuse.

I'm less clear about what happens to condition variables, but it
> does seem that perhaps terminating a process while it is waiting
> on a condition will cause other processes to deadlock.  Perhaps
> the wait conceptually returns and the mutex is re-locked during
> termination.
>

These are all tricky questions. POSIX gets away by deferring decision to
the user and it does work. The challenge here is adapting the problem to
the vocabulary of C++ objects model.

If we do proceed with your idea about read/write locks, the
PTHREAD_MUTEX_ROBUST solution could be mapped into the lock object.

unique_lock -> we can't assume anything, then we use this most broad
assumption: a write lock and no recovery mechanisms in using code
unique_read_lock -> read lock
unique_robust_lock -> stores extra data about the lock state that the user
can query after lock is acquired. This should be enough to map
PTHREAD_MUTEX_ROBUST behaviour and make it work with condition variables.

unique_robust_lock lk{mtx};
for (;;) {
  if (!lk.consistent()) {
    // mutex acquired
    // but in inconsistent state
    // user has to deal with it
  }
  if (predicate)
    break;
  cond.wait(lk);
}

What do you think?

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/