[Async-sig] "read-write" synchronization

[Chris Jerdonek]

On Tue, Jun 27, 2017 at 3:52 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Mon, Jun 26, 2017 at 6:41 PM, Chris Jerdonek
> <chris.jerdonek at 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