Hacker News Reader

Comment by sicromoft | Hacker News Reader

I think something might be off in your mental model of python coroutines. They work via cooperative multitasking. Atomic operations aren't really necessary or relevant in such a system where you are in complete control of all yield points (i.e., calls to `await`).

If you read the full blog post, the author solves the problem without setdefault, and without having to cancel any futures.

View on HN

I understand them quite well, thank you. You don't need setdefault if you only call the initializer from one thread. My code can be made thread safe (as long as you only use one event loop per thread).

It's way easier with a single thread. You don't need a lock or atomic operations.

    initializer = None
    async def maybe_initialize():
      global initializer
      if initializer is None:
        initializer = asyncio.ensure_future(one_time_setup())
      await initializer
      return

This is the same as the solution from the article, except that:

- Chris forgot to declare the variable as global;

- Chris used asyncio.create_task() instead of asyncio.ensure_future().

Thanks for pointing that out, for some reason I had thought the last implementation also used a lock.

Maybe it's me not grokking async, but the code seems right to me. `once` is a decorator, so `future` is "instantiated" once per decorated function, which is then accessed as nonlocal in the wrapper. So in the last code sample, every call to `one_time_setup()` is accessing the same `future`.

Since D is not being rebound, the global declaration is unneeded.

(Chris has added the global declaration since then.)

You have to make it clear you’re speaking of CPU atomics, because whatever atomic operations are trying to solve, for example mainly “read then write” operations - may still easily cause issues within asynchronous code.

Reply on news.ycombinator.com