Victor, thanks for merging.

> I'm surprised that we still find new bugs in this code which is supposed to
> be battle tested! Maybe recent Darwin changed made the bug more likely.

As discussed above (https://bugs.python.org/issue38106#msg351917,
https://bugs.python.org/issue38106#msg351970), due to the GIL, the bug is not
possible to trigger from pure-python code, and it can be hit only via using CAPI
directly. I indeed started to observe the problem after moving locks and
other code that implement channels in Pygolang from Python to C level (see
"0.0.3" in https://pypi.org/project/pygolang/#pygolang-change-history)

The bug was there since 1994 and, from my point of view, it was not discovered
because locking functionality was not enough hammer-tested. The bug was also
not possible to explain without taking lock lifetime into account, as, without
create/destroy, just lock/unlock sequence was race free. 
https://bugs.python.org/issue433625 confirms that.

I cannot say about whether recent macOS changes are relevant. My primary
platform is Linux and I only recently started to use macOS under QEMU for
testing. However from my brief study of https://github.com/apple/darwin-libpthread
I believe the difference in scheduling related to pthread condition variable
signalling under macOS and Linux is there already for a long time.

> PyPy: it's now your turn to fix it ;-)

PyPy people fixed the bug the same day it was reported:

https://bitbucket.org/pypy/pypy/issues/3072

:)

Kirill

P.S. Mariusz, thanks also for your feedback.