Main threads waits indefinitely on futures if single future calls condition.wait()

info at dantalion.nl info at dantalion.nl
Thu Oct 31 06:38:37 EDT 2019


Hello,

Recently I have been trying to use a reantrant read write lock in my
project but discovered several problems when writing test cases.

All the relevant material can be found on the following locations
https://stackoverflow.com/questions/58410610/calling-condition-wait-inside-thread-causes-retrieval-of-any-future-to-block-o
https://bugs.launchpad.net/futurist/+bug/1848457
https://github.com/Dantali0n/bug1848457

But let me describe it here as well.
I am using the futurist library maintained by the OpenStack foundation.
This library provides concurrency constructs similar to those of Python
itself. Among the functionality is a wait_for_any method which waits on
a list of futures and continuous once one of them is done().

However, when I submit two tasks to a threadpool which both attempt to
get a reantrant read write lock this wait_for_any method behaves
unexpectedly. Since both tasks attempt to get the lock concurrently one
will succeed and the other will not. The behavior of this lock is to
call condition.wait() if it does not succeed.

The unexpected behavior of the wait_for_any method is that in this
scenario it will block indefinitely when called even though one of the
futures is done() and finished successfully.

In https://github.com/Dantali0n/bug1848457 I have created a spin_for_any
using the same lock but with 'native' Python concurrency and here
calling future.done() does not block.

I was hoping someone had any clue as to what could cause this and how it
can be resolved. As mentioned before the question is also over on
stackoverflow, I have been struggling with this for a month now.

I hope someone has time to provide some help on this matter.

Kind regards,
Corne Lukken (Dantali0n)


More information about the Python-list mailing list