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 Sebastian.Noack
Recipients Sebastian.Noack, asvetlov, jyasskin, kristjan.jonsson, mklauber, pitrou
Date 2012-09-29.23:46:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Using a lock as context manager is the same as calling lock.acquire(blocking=True) and it will in fact block while waiting for an other thread to release the lock. In your code, the internal lock is indeed just hold for a very short period of time while acquiring or releasing a shared or exclusive lock, but it might add up to a notable amount of time dependent on how much concurrent threads are using the same RWLock and how slow/busy your computer is.

But what made me reconsider my point are following facts:

1. For example, when you acquire a shared (read) lock in non-blocking mode and False is returned, you assume that an other thread is holding an exclusive (write) lock. But that isn't necessarily the case, if it also returns False, when the internal lock is acquired by an other thread for example in order to acquire or release another shared (read) lock.

2. The internal lock must be acquired also in order to release a shared/exclusive lock. And the 'release' method (at least if implemented as for Lock and RLock) don't have a 'blocking' argument, anyway.

For that reasons, I think it is ok to block while waiting for the internal lock, even if the shared/exclusive lock was acquired in non-blocking mode. At least it seems to lead to less unexpected side effects, than returning False in case the internal lock is acquired.
Date User Action Args
2012-09-29 23:46:52Sebastian.Noacksetrecipients: + Sebastian.Noack, pitrou, kristjan.jonsson, jyasskin, asvetlov, mklauber
2012-09-29 23:46:52Sebastian.Noacksetmessageid: <>
2012-09-29 23:46:52Sebastian.Noacklinkissue8800 messages
2012-09-29 23:46:51Sebastian.Noackcreate