On Tue, Jun 27, 2017 at 3:52 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Mon, Jun 26, 2017 at 6:41 PM, Chris Jerdonek > <chris.jerdo...@gmail.com> wrote: >> I coded up a working version of the pseudo-code I included in an >> earlier email so people can see how it works. I included it at the >> bottom of this email and also in this gist: >> https://gist.github.com/cjerdonek/858e1467f768ee045849ea81ddb47901 > > FWIW, to me this just looks like an implementation of an async RWLock? > It's common for async synchronization primitives to be simpler > internally than threading primitives because the async ones don't need > to worry about being pre-empted at arbitrary points, but from the > caller's point of view you still have basically a blocking acquire() > method, and then you do your stuff (potentially blocking while you're > at it), and then you call a non-blocking release(), just like every > other async lock.
Yes and no I think. Internally, the implementation does just amount to applying an async RWLock. But the difference I was getting at is that the use case doesn't require exposing the RWLock in the API (e.g. underlying acquire() and release() methods). This means you can avoid having to think about some of the tricky design questions you started discussing in an earlier email of yours: > This is also a surprisingly complex design question. Your async RWLock > actually matches how Python's threading.Lock works: you're explicitly > allowed to acquire it in one thread and then release it from another. > People sometimes find this surprising, and it prevents some kinds of > error-checking. For example, this code *probably* deadlocks: > ... So my point was just that if the API is narrowed to exposing only "read" and "write" operations (to support the easier task of synchronizing reads and writes) and the RWLock kept private, you can avoid having to think through and support full-blown RWLock design and use cases, like with issues around passing ownership, etc. The API restricts how the RWLock is ever used, so it needn't be a complete RWLock implementation. --Chris _______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/