3 ms·
> async\await in no way relieve the developer from needing to worry about locks. If you have shared mutable memory, you have locks. If you aren't considering th
by Nullabillity 4y ago
> async\await in no way relieve the developer from needing to worry about locks. If you have shared mutable memory, you have locks. If you aren't considering that, then you've got broken code.
The huge difference is that futures (and thus async/await) change the primary concurrency concept you think about into "wait until this value is available" rather than managing the locks and shared memory yourself.
The latter is still available (and still as footgunny as ever) but aren't as much of a problem when better options are more ergonomic.
Futures also compose far better than threads do, especially when you want to wait for "any of X" rather than "all of X".
- pron 4y agoI don't understand the distinction you make between futures and threads. Virtual threads make working with futures more pleasant.
- cogman10 4y ago> The huge difference is that futures (and thus async/await) change the primary concurrency concept you think about into "wait until this value is available" rather than managing the locks and shared memory yourself. Java has had Futures for a while (and pretty good ones since Java 8's addition of "CompletableFuture") That being said, the biggest issue with Java Futures has not been the futures themselves, but rather the management of the ThreadPools for when you want to do IO in the futures. As pron points out, virtual threads make that WAY better to work with.