4 ms·

>async\await in no way relieve the developer from needing to worry about locks. If you have shared mutable memory, you have locks. This isn't really true. For

by jayd16 5y ago

>async\await in no way relieve the developer from needing to worry about locks. If you have shared mutable memory, you have locks. This isn't really true. For example, UI code often uses async/await for the concurrency but a single UI thread to prevent locking. Because this design is only concurrent and not parallel you don't need to worry about thread safety while still getting a way to yield execution to other code.

pmoleri 5y ago
I think it depends on the language. What you say is true for JS because it's single threaded but .Net has a thread pool, that means that you can have concurrent and even parallel tasks attending different events from your single thread UI.
- jayd16 5y ago
  You cannot use a single UI thread in a parallel way. Its a contradictory statement. Parallel is the opposite of single threaded. C# does have a thread pool that you can use with async/await with multiple threads but that would be different from a UI thread or its synchronization context.
  - pmoleri 5y ago
    It's not contradictory, the UI is single threaded but on the dispatched events you can perfectly have long running tasks that can perform parallel work and affefct common memory. It's also my understanding that if you stick to async/await and don't create your own tasks, the synchronization context will be the one of the UI thread thus never run in parallel. However, this doesn't prevent you from doing so.
    - jayd16 5y ago
      Ah I see what you mean. Sure, you can do that if you desire. My point was simply that the system allows you to not do that. It's easy to get concurrency without parallelism. And it's also easy to get parallelism. But yes, In C# you're only guarded by self control and the slightly cumbersome calls it takes to jump threading context. It's not hard to stay in a single context but it's not enforced.
      - gpderetta 5y ago
        But you can do the same with threads: pin them to a single cpu/scheduler and use a non-preemptive scheduling strategy. At some point you realize that explicit continuation passing, threads, coroutines and async/await are all the same thing, and the only thing that async/await gives you is a static bound on your suspended stack size (by enforcing suspension of a single activation frame).

by jayd16 5y ago

pmoleri 5y ago

I think it depends on the language. What you say is true for JS because it's single threaded but .Net has a thread pool, that means that you can have concurrent and even parallel tasks attending different events from your single thread UI.

jayd16 5y ago
You cannot use a single UI thread in a parallel way. Its a contradictory statement. Parallel is the opposite of single threaded. C# does have a thread pool that you can use with async/await with multiple threads but that would be different from a UI thread or its synchronization context.
- pmoleri 5y ago
  It's not contradictory, the UI is single threaded but on the dispatched events you can perfectly have long running tasks that can perform parallel work and affefct common memory. It's also my understanding that if you stick to async/await and don't create your own tasks, the synchronization context will be the one of the UI thread thus never run in parallel. However, this doesn't prevent you from doing so.
  - jayd16 5y ago
    Ah I see what you mean. Sure, you can do that if you desire. My point was simply that the system allows you to not do that. It's easy to get concurrency without parallelism. And it's also easy to get parallelism. But yes, In C# you're only guarded by self control and the slightly cumbersome calls it takes to jump threading context. It's not hard to stay in a single context but it's not enforced.
    - gpderetta 5y ago
      But you can do the same with threads: pin them to a single cpu/scheduler and use a non-preemptive scheduling strategy. At some point you realize that explicit continuation passing, threads, coroutines and async/await are all the same thing, and the only thing that async/await gives you is a static bound on your suspended stack size (by enforcing suspension of a single activation frame).