3a449bbb69c9a3c3a5bc6a052f2de98ab79be7e9 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
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
(cherry picked from commit fddeec60cba806b88c5eb0e4758c3951457518a2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
22c48a4e02