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 lukasz.langa
Recipients asvetlov, fried, lukasz.langa, yselivanov
Date 2018-05-23.18:32:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1527100332.08.0.682650639539.issue33546@psf.upfronthosting.co.za>
In-reply-to
Content
Andrew is right because a Condition *is* a lock.  The confusing thing about this construct is that the actual logic "condition" that we're waiting for is external.


It can be controlled by another coroutine that will just let us know by calling `cond.notify()` when the condition is met.  On the receiver side it looks like this:

    async with cond:       # in this block you hold the lock
        await cond.wait()  # (this temporarily releases the lock as long as it waits)
        print("Another coroutine called .notify().  I hold the lock now!")


It can also be used like Andrew demonstrated above, where *we* run the logic "condition" check ourselves and that check *also* requires a lock to be correct:

    async with cond:                              # in this block you hold the lock
        while not condition_check_with_lock():    # <- this is the actual "condition" check
            await cond.wait()                     # (temporarily releases the lock while it waits)
        print("Check passed and I'm holding the lock now!")


Personally I find the latter example confusing because it doesn't require another coroutine to ever `.notify()` us if the initial `condition_check_with_lock()` returned True, but it *does* require another coroutine to `.notify()` us if that initial check returned False.
History
Date User Action Args
2018-05-23 18:32:12lukasz.langasetrecipients: + lukasz.langa, asvetlov, yselivanov, fried
2018-05-23 18:32:12lukasz.langasetmessageid: <1527100332.08.0.682650639539.issue33546@psf.upfronthosting.co.za>
2018-05-23 18:32:12lukasz.langalinkissue33546 messages
2018-05-23 18:32:12lukasz.langacreate