This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vilnis.termanis
Recipients vilnis.termanis
Date 2015-10-24.10:09:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za>
In-reply-to
Content
multiprocessing's Condition uses a couple of semaphores to keep track of
processes which are sleeping and have woken up whilst waiting for the
condition. These counters however are only ever decremented in the
notify(_all) functions, via a loop which results in somewhat unexpected
behaviour where said functions take longer to run than expected.

The proposed patch simplifies notify(_all) functions such that time complexity
is still O(N) but crucially N is the number of currently sleeping processes
only (rather than number of wait() calls since last notify(_all) call).

Note: This also affects Event.wait() & Event.set() in the same fashion since a
Condition is used under the hood.

I've attached mp_sync_condition.patch based on "in-development" branch as of
98840:2028aed246c0. I have run unit tests on said commit (via debug build)
using:

./python -bb -E -Wd -m test -r -v -uall\
    test_multiprocessing_fork\
    test_multiprocessing_fork\
    server test_multiprocessing_spawn

Additionally I've run condition_test.py before & after to illustrate performance
of the proposed change as well as demonstrate the issue.
History
Date User Action Args
2015-10-24 10:09:55vilnis.termanissetrecipients: + vilnis.termanis
2015-10-24 10:09:55vilnis.termanissetmessageid: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za>
2015-10-24 10:09:55vilnis.termanislinkissue25469 messages
2015-10-24 10:09:54vilnis.termaniscreate