Other than the clickbait-y title, the article is a decent one.
I only want to point out that the described issue with cond var signal/broad cast while not holding the mutex is not correct. You are definitely allowed to call signal/broadcast after releasing the lock, as long as the state was modified with the lock held. In fact this is a common performance optimization. Of course trying to be clever and attempting to modify the state outside the critical section (or not acquiring the mutex at all) will only lead to pains.
Assuming that waits are done correctly (i.e. checking the condition in a loop), what the author is probably experiencing is missed wakeups due to using signal (as opposed to broadcast) with multiple waiters waiting for slightly different conditions. This is not an issue with condvar per se, but with the client code itself.
Normally broadcast fixes many missed wakeup issues but not always.
I only want to point out that the described issue with cond var signal/broad cast while not holding the mutex is not correct. You are definitely allowed to call signal/broadcast after releasing the lock, as long as the state was modified with the lock held. In fact this is a common performance optimization. Of course trying to be clever and attempting to modify the state outside the critical section (or not acquiring the mutex at all) will only lead to pains.
Assuming that waits are done correctly (i.e. checking the condition in a loop), what the author is probably experiencing is missed wakeups due to using signal (as opposed to broadcast) with multiple waiters waiting for slightly different conditions. This is not an issue with condvar per se, but with the client code itself.
Normally broadcast fixes many missed wakeup issues but not always.