On Tue, Jun 27, 2017 at 3:52 PM, Nathaniel Smith wrote:
> On Mon, Jun 26, 2017 at 6:41 PM, Chris Jerdonek
> 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 gis
On Mon, Jun 26, 2017 at 6:41 PM, Chris Jerdonek
wrote:
> On Mon, Jun 26, 2017 at 12:37 PM, Dima Tisnek wrote:
>> Chris, here's a simple RWLock implementation and analysis:
>> ...
>> Obv., this code could be nicer:
>> * separate context managers for read and write cases
>> * .unlock can be automat
On Mon, Jun 26, 2017 at 12:37 PM, Dima Tisnek wrote:
> Chris, here's a simple RWLock implementation and analysis:
> ...
> Obv., this code could be nicer:
> * separate context managers for read and write cases
> * .unlock can be automatic (if self.writer: unlock_for_write()) at the
> cost of openin
On Mon, Jun 26, 2017 at 12:37 PM, Dima Tisnek wrote:
> Note that `.unlock` cannot validate that it's called by same coroutine
> as `.lock` was.
> That's because there's no concept for "current_thread" for coroutines
> -- there can be many waiting on each other in the stack.
This is also a surpris
- self.cond.wait()
+ await self.cond.wait()
I've no tests for this :P
On 26 June 2017 at 21:37, Dima Tisnek wrote:
> Chris, here's a simple RWLock implementation and analysis:
>
> ```
> import asyncio
>
>
> class RWLock:
> def __init__(self):
> self.cond = asyncio.Condition()
>
Chris, here's a simple RWLock implementation and analysis:
```
import asyncio
class RWLock:
def __init__(self):
self.cond = asyncio.Condition()
self.readers = 0
self.writer = False
async def lock(self, write=False):
async with self.cond:
# wri
On Mon, Jun 26, 2017 at 10:02 AM, Dima Tisnek wrote:
> Chris, coming back to your use-case.
> Do you want to synchronise side-effect creation/deletion for the
> sanity of side-effects only?
> Or do you imply that callers' actions are synchronised too?
> In other words, do your callers use those di
A little epiphany on my part:
In threaded world, a lock (etc.) can be used for 2 distinct purposes:
*1 synchronise [access to resource in the] library implementation, and
*2 synchronise users of a library
It's easy since taken lock has an owner (thread).
Both library and user stack frames belong
On Mon, Jun 26, 2017 at 1:43 AM, Dima Tisnek wrote:
> Perhaps you can share your use-case, both as pseudo-code and a link to
> real code.
>
> I'm specifically interested to see why/where you'd like to use a
> read-write async lock, to evaluate if this is something common or
> specific, and if, per
Chris, this led to an interesting discussion, which then went pretty
far from the original concern.
Perhaps you can share your use-case, both as pseudo-code and a link to
real code.
I'm specifically interested to see why/where you'd like to use a
read-write async lock, to evaluate if this is some
On Sun, Jun 25, 2017 at 10:33 PM, Guido van Rossum
wrote:
> On Sun, Jun 25, 2017 at 3:38 PM, Yarko Tymciurak
> wrote:
>
>> 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 laten
On Sun, Jun 25, 2017 at 10:46 PM, Yarko Tymciurak wrote:
>
>
> On Sun, Jun 25, 2017 at 10:33 PM, Guido van Rossum
> wrote:
>
>> On Sun, Jun 25, 2017 at 3:38 PM, Yarko Tymciurak
>> wrote:
>>
>>> To be a well-behaved (capable of effective cooperation) task in such a
>>> system, you should guard a
On Sun, Jun 25, 2017 at 3:38 PM, Yarko Tymciurak wrote:
> 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 c
So here's one approach I'm thinking about for implementing
readers-writer synchronization. Does this seem reasonable as a
starting point, or am I missing something much simpler?
I know there are various things you can prioritize for (readers vs.
writers, etc), but I'm less concerned about those fo
On Sun, Jun 25, 2017 at 4:54 PM Chris Jerdonek
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
>
On Sun, Jun 25, 2017 at 3:09 PM, Nathaniel Smith wrote:
> On Sun, Jun 25, 2017 at 2:13 PM, Chris Jerdonek
> wrote:
>> I'm using asyncio, and the synchronization primitives that asyncio
>> exposes are relatively simple [1]. Have options for async read-write
>> synchronization already been discusse
On Sun, Jun 25, 2017 at 2:13 PM, Chris Jerdonek
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]. Hav
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" 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,
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 ca
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
wrote:
> There is https://github.com/aio-libs/aiorwlock
>
> On Mon, Jun 26, 2017 at 12:13 AM Chris Jerdonek
> wrote:
>>
>> I'm re
There is https://github.com/aio-libs/aiorwlock
On Mon, Jun 26, 2017 at 12:13 AM Chris Jerdonek
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
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 discu
22 matches
Mail list logo
