[Async-sig] "read-write" synchronization

[Yarko Tymciurak]

On Sun, Jun 25, 2017 at 4:54 PM Chris Jerdonek <chris.jerdonek at gmail.com>
wrote:

> The read-write operations I'm protecting will have coroutines inside
> that need to be awaited on, so I don't think I'll be able to take
> advantage to that extreme.
>
> But I think I might be able to use your point to simplify the logic a
> little. (To rephrase, you're reminding me that context switches can't
> happen at arbitrary lines of code. I only need to be prepared for the
> cases where there's an await / yield from.)


The "secret" Guido refers to we should pull out front and center,
explicitly at all times - asynchronous programming is nothing more than
cooperative multitasking.

Patterns suited for preemptive multi-tasking (executive-based, interrupt
based, etc.) are suspect, potentially misplaced when they show up in a
cooperative multitasking context.

To be a well-behaved (capable of effective cooperation) task in such a
system, you should guard against getting embroiled in potentially blocking
I/O tasks whose latency you are not able to control (within facilities
available in a cooperative multitasking context).  The raises a couple of
questions: to be well-behaved, simple control flow is desireable (i.e. not
nested layers of yields, except perhaps for a pipeline case); and
"read/write" control from memory space w/in the process (since external I/O
is generally not for async) begs the question: what for?  Eliminate
globals, encapsulate and limit access as needed theough usual programming
methods.

I'm sure someone will find an edgecase to challenge my above rule-of-thumb,
but as you're new to this, I think this is a pretty good place to start.
Ask yourself if what your trying to do w/ async is suited for async.

Cheers,
Yarko

>
>
> --Chris
>
>
> On Sun, Jun 25, 2017 at 2:30 PM, Guido van Rossum <gvanrossum at gmail.com>
> wrote:
> > The secret is that as long as you don't yield no other task will run so
> you
> > don't need locks at all.
> >
> > On Jun 25, 2017 2:24 PM, "Chris Jerdonek" <chris.jerdonek at gmail.com>
> wrote:
> >>
> >> Thank you. I had seen that, but it seems heavier weight than needed.
> >> And it also requires locking on reading.
> >>
> >> --Chris
> >>
> >> On Sun, Jun 25, 2017 at 2:16 PM, Andrew Svetlov
> >> <andrew.svetlov at gmail.com> wrote:
> >> > There is https://github.com/aio-libs/aiorwlock
> >> >
> >> > On Mon, Jun 26, 2017 at 12:13 AM Chris Jerdonek
> >> > <chris.jerdonek at gmail.com>
> >> > wrote:
> >> >>
> >> >> I'm relatively new to async programming in Python and am thinking
> >> >> through possibilities for doing "read-write" synchronization.
> >> >>
> >> >> I'm using asyncio, and the synchronization primitives that asyncio
> >> >> exposes are relatively simple [1]. Have options for async read-write
> >> >> synchronization already been discussed in any detail?
> >> >>
> >> >> I'm interested in designs where "readers" don't need to acquire a
> lock
> >> >> -- only writers. It seems like one way to deal with the main race
> >> >> condition I see that comes up would be to use loop.time(). Does that
> >> >> ring a bell, or might there be a much simpler way?
> >> >>
> >> >> Thanks,
> >> >> --Chris
> >> >>
> >> >>
> >> >> [1] https://docs.python.org/3/library/asyncio-sync.html
> >> >> _______________________________________________
> >> >> Async-sig mailing list
> >> >> Async-sig at python.org
> >> >> https://mail.python.org/mailman/listinfo/async-sig
> >> >> Code of Conduct: https://www.python.org/psf/codeofconduct/
> >> >
> >> > --
> >> > Thanks,
> >> > Andrew Svetlov
> >> _______________________________________________
> >> Async-sig mailing list
> >> Async-sig at python.org
> >> https://mail.python.org/mailman/listinfo/async-sig
> >> Code of Conduct: https://www.python.org/psf/codeofconduct/
> _______________________________________________
> Async-sig mailing list
> Async-sig at python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20170625/7cf7e88c/attachment.html>