3 ms·

> The difference between async/await and pre-emption is that execution will only yield at an await instead of possibly any time. Yes, that’s a critical section

> The difference between async/await and pre-emption is that execution will only yield at an await instead of possibly any time. Yes, that’s a critical section. Every thread on your computer is constantly being preempted by the OS thread scheduler. It doesn’t matter to your code, just like it doesn’t matter in a preemptive task system, unless you are manipulating global state without a lock and someone else is trying to manipulate it behind your back. Preemption is a feature, not a bug. > And yes, you _can_ guarantee task order A then B by having Task B await A. What…? The whole point is that these are separate tasks started by the GUI framework as asynchronous callbacks. They can’t wait on each other because they don’t know about each other. If you think Go code can’t run its own instructions in a specific order… what?! So of course Go could do that too. But that’s not at all what I’m discussing! > However, you're focusing on task order, I'm talking about the order of instructs of a tasks acting like critical sections. I just don’t feel like you know how Go works. The order of instructions is the order you write them, barring any funny compiler optimizations which also apply to C#. It’s not “magically” running all instructions of your function in parallel or something. Whether the task gets interrupted or not is irrelevant — it will resume where it left off. As long as you synchronize access to global state, no one will be observe the interruptions to the task, exactly like how your operating system is interrupting your program constantly and you can’t even tell. “Implicit threading” isn’t even the right term here, since that implies the compiler or runtime is automatically forking your code into parallel sections for efficiency. Go does not do this. If you write a for loop, it executes every loop iteration sequentially. It doesn’t do wacky things like you seem to believe. > You can bemoan the fact that UI systems are designed around single thread access, that that's messy or whatever but its just the reality. That’s not at all what I’m “bemoaning”. If that’s what you’ve gotten from this conversation, then I’m utterly bewildered. I’m done trying to get my points across if communication has broken down to this degree.

jayd16 5y ago
Parallel and concurrent are not the same. I'm talking about preventing concurrency of UI tasks. You can guarantee A1-A2-B1-B2 instead of A1-AYield-B1-B2-A2 if you have control of what will yield. With pre-emption, A might unexpectedly yield mid-execution and B could run, even when scheduled to a single thread. >Whether the task gets interrupted or not is irrelevant — it will resume where it left off. As long as you synchronize access to global state [...] Cooperative multithreading like async/await is leveraging the fact that actually if you control the interruption, THAT can be your synchronization. You don't need locks. UI programming is usually lock free. A UI thread is more commonly used. Understanding that, you can see that pre-emption _is_ sometimes a bug.
- coder543 5y ago
  To quote myself: >>>> If you never yield, then sure, but... that's not very useful in an asynchronous context. You might as well just go back to writing blocking C event loops where every task always runs to completion before any other task can start. What you're talking about isn't what most people talk about or experience in regards to C# async, and it's still not an actual benefit. In all cases described so far, you're better off explicitly writing A to call B than to try to misuse an async task executor as a weird queue, especially as you said yourself that there is no yielding involved. It's really that simple. What you have described is incredibly brittle code riddled with implicit dependencies, and since you're not yielding, you are locking up the UI.
  - jayd16 5y ago
    You still don't get it. Its not that there is no yielding. Its that you as the developer have precise control of when and where to yield. ...But anyway, forget it. I'll be more than happy to use a multi-threaded UI system when such a thing exists.

jayd16 5y ago

Parallel and concurrent are not the same. I'm talking about preventing concurrency of UI tasks. You can guarantee A1-A2-B1-B2 instead of A1-AYield-B1-B2-A2 if you have control of what will yield. With pre-emption, A might unexpectedly yield mid-execution and B could run, even when scheduled to a single thread. >Whether the task gets interrupted or not is irrelevant — it will resume where it left off. As long as you synchronize access to global state [...] Cooperative multithreading like async/await is leveraging the fact that actually if you control the interruption, THAT can be your synchronization. You don't need locks. UI programming is usually lock free. A UI thread is more commonly used. Understanding that, you can see that pre-emption _is_ sometimes a bug.

coder543 5y ago
To quote myself: >>>> If you never yield, then sure, but... that's not very useful in an asynchronous context. You might as well just go back to writing blocking C event loops where every task always runs to completion before any other task can start. What you're talking about isn't what most people talk about or experience in regards to C# async, and it's still not an actual benefit. In all cases described so far, you're better off explicitly writing A to call B than to try to misuse an async task executor as a weird queue, especially as you said yourself that there is no yielding involved. It's really that simple. What you have described is incredibly brittle code riddled with implicit dependencies, and since you're not yielding, you are locking up the UI.
- jayd16 5y ago
  You still don't get it. Its not that there is no yielding. Its that you as the developer have precise control of when and where to yield. ...But anyway, forget it. I'll be more than happy to use a multi-threaded UI system when such a thing exists.