Perhaps you could avoid this potentially infinite wait by having w_acquire acquire num_r_lock, and w_release release it? So if I understand correctly, as long as any readers are reading, more can be added on even if there is a writer waiting. The reason it terminates when you uncomment the print() line is that the print() line is slow enough that it dramatically increases the probability that at some point all of the read threads will not be holding on to the read lock. However, that does not make the other libraries better - the opposite, those libraries are actually slower, and even for those slow libraries it's bad practice to count on them being slow as a means to ensure your write threads are not starved. In that case it's less likely to starve the write lock. The reason this same code may work with other libraries is that their locking stage may be slower than this code.

Another option is to somehow fence the readers so that every once in a while they will all simultaneously let go of the read lock. A simple way to do this is to only have a single reader thread that regularly releases the read lock. If you have both readers and writers, then it's up to you to ensure that at some point all of the readers will stop reading in order to allow the writers to write. What's happening is that the read locks are starving the write threads, so today never gets a chance to change.

''' This method is designed to be used via the `with` statement. Multiple threads, but only written to by a single thread at a time. ''' RWLock class this is meant to allow an object to be read from by This is implemented with two mutexes (threading.Lock instances) as per thisĬode written by Tyler Neylon at Unbox Research. A class to implement read-write locks on top of the standard threading

Reader writer code