4 ms·
async/await is more flexible in some sense. If you run the tasks on a thread pool, it's mostly equivalent to green threads. But if you run the tasks on a single
by ynik 6y ago
async/await is more flexible in some sense. If you run the tasks on a thread pool, it's mostly equivalent to green threads.
But if you run the tasks on a single thread, you get cooperative multi-tasking. You can access mutable shared state without using locks, as long as you don't use "await" while the shared state is in an inconsistent state.
For user interfaces this is huge advantage: you can run all your code on the UI thread; but the UI stays responsive while awaiting tasks.
Also, here's an interesting use of async/await: software hyperthreading: https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-to-the-rescue-using-coroutines-ts-of-course-g https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-...
- pron 6y agoLoom's virtual threads allow you to do the same with a pluggable scheduler.
- jayd16 6y agoHow does UI code work in Loom if you need, say, a single render thread to issue GL commands? Wouldn't you need a native thread (making Loom moot), or is there some other trick at play?
- pjmlp 6y agoYou can still pick and choose, native threads aren't going away, just like today you can make several tasks map to a single threaded.
- jayd16 6y agoAlright. The trick is to not use Loom virtual threads. I will say Java's Loom is ruthlessly elegant in this way. But won't you run into issues where you don't want to call certain code from that UI thread? Isn't that "code coloring"?
- pjmlp 6y agoCode colouring usually means it won't even compile, like on C# async/await case. In your example, for Swing applications you should use invokeLater(Runnable r) anyway, and it doesn't matter what implements the interface.
- pron 6y agoYou would use a custom scheduler to schedule many virtual threads onto a particular native thread.
- jayd16 6y agoI don't think this is enough. You still might interweave your draw commands, causing issues.
- pron 6y agoYou can get the exact same result as with async/await.
- jayd16 6y agoIf you have multiple virtual threads issuing non-atomic commands that must be run together and not interwoven, how does the scheduler know when it's ok to yield one thread to another without explicit support? How can you set a shader and then draw a mesh each in two virtual threads without possibly interweaving their execution, for example?
- nuclear_eclipse 6y ago>For user interfaces this is huge advantage: you can run all your code on the UI thread; but the UI stays responsive while awaiting tasks. ... assuming any other tasks/coroutines running on the UI thread are being cooperative and not doing bad things like waiting on synchronous functions or otherwise hogging the UI thread too much. Done right, it's a big performance and maintainability win over multithreading, but when done poorly, it can result in large variance in latency/responsiveness of any individual task.