![](https://secure.gravatar.com/avatar/273890f5944345c84e255cdd6efcfb35.jpg?s=120&d=mm&r=g)
On Sun, Jun 25, 2017 at 4:54 PM Chris Jerdonek <chris.jerdonek@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@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@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@gmail.com> wrote:
There is https://github.com/aio-libs/aiorwlock
On Mon, Jun 26, 2017 at 12:13 AM Chris Jerdonek <chris.jerdonek@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@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@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@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/