Pushed, without that test.
I realised that the test would not be stable in the build farm. If we
made the lock timeout high, the test would be slow, but if we made it
low, then there would be two possible outputs depending on a race, and
10ms as you had it seems -- I guess? -- likely to be unstable under
valgrind or an RPi2 or something. There is probably some clever way
to write a different test schedule, but the new code is exercised by
existing tests, and the assertion has been failing once every couple
of days on CI since I started collecting that data a few weeks ago, so
we have some kind of coverage, at least for master.