[cpp-threads] Comments on n2094

[Peter Dimov]

Some brief comments:

Ion Gaztañaga wrote:

> a) The first consequence is that implementing an upgradable_mutex
> using the suggested two condition variables + a mutex is not correct,
> since all operations (including unlock()) will need to lock the
> internal mutex, and that internal mutex locking can throw. Not that
> this is worries me much, but it's a bit annoying.

This is only a problem if mutex::lock can succeed once and fail the second 
time. This is usually not true for designs where failure comes from 
allocating resources on first lock.

> Other implementations can detect that the thread/process
> owning the mutex has died, returning an error in the lock function in
> other threads.

This particular case can be handled by making the lock succeed. It could be 
returned via a "succeeded but..." error code, if mutex::lock is respecified 
to return one.

However there is, indeed, a general problem with EDEADLK and you make a good 
point that it should probably not result in an exception (or if it does, the 
outer unlock function needs to have a throw() spec and terminate.)

> 0.1 Condition variables
> ------------------------
>
> Condition variables and exceptions are a very tricky combination,
> IMHO. In this proposal, the situation is more tricky, since condition
> variables can work with user-defined mutexes (which is a great
> feature). If mutex locking can throw, that means that condition wait
> can also throw, since it must lock the mutex after it's been
> notified.

condition::wait is a cancelation point and it can fail with EINVAL or EPERM, 
so it doesn't matter whether locking a mutex can throw; condition::wait can 
throw.

> What is the user supposed to do if a condition throws? Can the user
> recover resources and try it again? Can we guarantee that the mutex
> will be always relocked?

POSIX says yes. The mutex is in a locked state when pthread_cond_wait 
"throws" a cancelation exception or returns an error.