3a449bbb69 amended the code to remove
acquiring a lock when waking up a condition variable. It is fine to
not have a lock associated when waking a condition variable; what I
misunderstood was the scope of the lock, which (and this underlines
the importance of commenting _what exactly_ a lock protects, for
each and ever lock) protected both the buffer as well as the counter
of the buffer. This made my reasoning flawed: it is necessary to keep
the lock while notifying, otherwise the counterpart could verify the
condition isn't satisfied and wait (e.g. see numUsedBytes==0), missing
the wake from the other thread (which could arrive between the check and
the wait).
Amends the previous commit.
Change-Id: If7db2d045331f1b33b976fb6bf6aa9117c41678f
Pick-to: 5.15 6.2 6.4 6.5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
fddeec60cb