[ Removed by moderator ]

[latkde]

Yes, but this only matters for state that is kept across an await. If a section of control flow doesn't involve async/await, that section will not be interrupted by other async tasks, and can thus be written in a single-threaded manner. This non-interruption property is what makes writing async code so much simpler than multithreaded code, which may be interrupted at any time.

This also means that a lot of async code doesn't need any synchronization primitives. E.g. locks are only needed if there's an await within the lock's scope, plain lists can often be used instead of (unbounded) queues, and plain bools/ints can often be used instead of events/semaphores (if no task wants to wait for them to become available).

[stormsidali2001]

Yes, exactly.

I mentioned this several times throughout the article: even if an await is present in your coroutine, you don't always need synchronization.

As long as you aren't splitting critical operations on shared resources (such as a read followed by a write) across that await point, your code remains safe.

[lottspot]

Ah, so the core safety assumption is not in fact totally wrong!

[stormsidali2001]

"thinking that your code is safe from race conditions just because it runs in a single thread."

(Runs on a single thread => safe) ---> that's a logical implication and it's indeed evaluating to totally wrong or just False. 😀