3 ms·

I don't think I agree. If there is any other code that touches account.balance from any other thread of execution (OS thread, coroutine, etc), then this code i

I don't think I agree. If there is any other code that touches account.balance from any other thread of execution (OS thread, coroutine, etc), then this code is already not safe. If there isn't any other thread of execution, then this is safe regardless of whether the call to Logger.Write is sync or async. For example, the following program would be safe regardless of whether Logger.Write is sync or async: int main() { InitLogger(); ChargeAccount(acc, 10); // the program will only ever get here after // account.balance = newBalance has finished executing ChargeAccount(acc, 10); } While the following program is not safe even if Logger.Write is sync: int main() { InitLogger(); launchInNewThread(() => ChargeAccount(acc, 10)); launchInNewThread(() => ChargeAccount(acc, 10)); } Transparent async a la Java Loom or Go does not spawn extra threads - it just pauses the current thread and schedules a new thread whenever you're waiting for a sync call (which normally means waiting for the kernel, either in IO or some kind of lock). In fact, the first program if written with something like Loom would be perfectly equivalent to the following C#: async void ChargeAccount(Account account, int cents) { int balance = account.balance; int newBalance = balance - cents; await Logger.Write("changing account from {balance} to {newBalance}"); account.balance = newBalance; } public static void Main(string[] args) { InitLogger(); await ChargeAccount(account, 5); await ChargeAccount(account, 5); } No concurrency regardless of underlying thread pools. You seem to assume it is equivalent to something like this, which would indeed be unsafe, but is not the case: public static void Main(string[] args) { InitLogger(); var t1 = ChargeAccount(account, 5); var t2 = ChargeAccount(account, 5); await Tasks.AwaitAll(t1, t2); }

fiddlerwoaroof 6y ago
Yeah, I think this is right: concurrency issues have to be solved by using data structures with concurrency semantics (software transactional memory or atomic refs/ints) and can’t really be solved by something like async/await. Go making you use channels to express asynchronous execution here is a feature, not a bug. async/await and friends (generators, callback-passing, etc.) all provide some clues that are sometimes useful for solving concurrency problems, but they aren’t able to make unsafe programs safe.
- Arnavion 6y ago
  >async/await and friends (generators, callback-passing, etc.) all provide some clues that are sometimes useful for solving concurrency problems, Exactly what I said. >but they aren’t able to make unsafe programs safe. Exactly not what I said either.
Arnavion 6y ago
>If there is any other code that touches account.balance from any other thread of execution (OS thread, coroutine, etc), then this code is already not safe. My point is about concurrency, not parallelism. I didn't mention anything about threads, let alone that there's more than one thread involved or that threads are being spawned. Take a simple node.js program or a Rust program that has a single-threaded tokio executor, or a C# WinForm program that reuses the UI thread for running Tasks, and everything I wrote applies. A single Account value used to be fine to be shared between coroutines because only one invocation of ChargeAccount would be active at a time, but the "transparent async" breaks that assumption. Explicit async-await makes it more obvious that multiple invocations of ChargeAccount might interleave unless proven otherwise, and the programmer has a reason to confirm that it is not the case, or use locking / atomics as necessary. >You seem to assume it is equivalent to something like this, which would indeed be unsafe, but is not the case: That `Task.WaitAll` program is indeed what I'm talking about, though the part of you thinking that I was talking about it being equivalent to a multi-threaded program is bogus.
- simiones 6y ago
  > Take a simple node.js program or a Rust program that has a single-threaded tokio executor, or a C# WinForm program that reuses the UI thread for running Tasks, and everything I wrote applies. A single Account value used to be fine to be shared between coroutines because only one invocation of ChargeAccount would be active at a time, but the "transparent async" breaks that assumption. That's not true at all. Here is a simple NodeJS implementation that is completely unsafe despite having non-transparent async: function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } async function LoggerWrite(s) { await delay(Math.random() * 100); console.log(s); } async function ChargeAccount(account, cents) { let balance = account.balance; let newBalance = balance - cents; await LoggerWrite("changing account from "+ balance + " to " + newBalance); account.balance = newBalance; } async function Main() { let account = {balance: 0}; let t1 = ChargeAccount(account, 1); let t2 = ChargeAccount(account, 20); let t3 = ChargeAccount(account, 18); let t4 = ChargeAccount(account, 12); await Promise.all([t1, t2, t3, t4]); console.log(account); } Main() //will randomly end up with -1 or -12 or -18 or -20, instead of the expected -51 And here is a Go program that does the right thing even with transparent async: func LoggerWrite(s string) { <-time.After(100) //this means "block for 100 ms" fmt.Println(s) } func ChargeAccount(account *account, cents int) { balance := account.balance newBalance := balance - cents LoggerWrite(fmt.Sprintf("changing account from %d to %d", balance, newBalance)) account.balance = newBalance } func main() { account := account{balance: 0} ChargeAccount(&account, 1) ChargeAccount(&account, 20) ChargeAccount(&account, 18) ChargeAccount(&account, 12) fmt.Printf("%+v\n", account) } //will ultimately print -51 You can try these yourself: NodeJS: https://replit.com/talk/share/Async-race-condition/138001 https://replit.com/talk/share/Async-race-condition/138001 Go: https://play.golang.org/p/ypKfQFUF5M2 https://play.golang.org/p/ypKfQFUF5M2 Edit: > Explicit async-await makes it more obvious that multiple invocations of ChargeAccount might interleave unless proven otherwise, and the programmer has a reason to confirm that it is not the case, or use locking / atomics as necessary. As shown by the example above, I think almost the opposite is true: async/await take code that looks linear and single-threaded and make it run concurrently. It's easy to accidentally end up with code like the JS one. Even worse, it's easy to accidentally call async code without await-ing it at all, and have unexpected behavior. By contrast, transparent async + cheap coroutines means that you can make all of your APIs blocking, and rely on the user explicitly spawning a coroutine if they want any kind of parallel/concurrent behavior, at the call site. In the Go code, I could have called `go ChargeAccount(...)` if I wanted the ChargeAccount calls to happen in parallel - I would have explicitly created parallelism, and I would have known to be careful of sharing the same pointer with the coroutines running concurrently.

fiddlerwoaroof 6y ago

Yeah, I think this is right: concurrency issues have to be solved by using data structures with concurrency semantics (software transactional memory or atomic refs/ints) and can’t really be solved by something like async/await. Go making you use channels to express asynchronous execution here is a feature, not a bug. async/await and friends (generators, callback-passing, etc.) all provide some clues that are sometimes useful for solving concurrency problems, but they aren’t able to make unsafe programs safe.

Arnavion 6y ago
>async/await and friends (generators, callback-passing, etc.) all provide some clues that are sometimes useful for solving concurrency problems, Exactly what I said. >but they aren’t able to make unsafe programs safe. Exactly not what I said either.

Arnavion 6y ago

>If there is any other code that touches account.balance from any other thread of execution (OS thread, coroutine, etc), then this code is already not safe. My point is about concurrency, not parallelism. I didn't mention anything about threads, let alone that there's more than one thread involved or that threads are being spawned. Take a simple node.js program or a Rust program that has a single-threaded tokio executor, or a C# WinForm program that reuses the UI thread for running Tasks, and everything I wrote applies. A single Account value used to be fine to be shared between coroutines because only one invocation of ChargeAccount would be active at a time, but the "transparent async" breaks that assumption. Explicit async-await makes it more obvious that multiple invocations of ChargeAccount might interleave unless proven otherwise, and the programmer has a reason to confirm that it is not the case, or use locking / atomics as necessary. >You seem to assume it is equivalent to something like this, which would indeed be unsafe, but is not the case: That `Task.WaitAll` program is indeed what I'm talking about, though the part of you thinking that I was talking about it being equivalent to a multi-threaded program is bogus.

simiones 6y ago
> Take a simple node.js program or a Rust program that has a single-threaded tokio executor, or a C# WinForm program that reuses the UI thread for running Tasks, and everything I wrote applies. A single Account value used to be fine to be shared between coroutines because only one invocation of ChargeAccount would be active at a time, but the "transparent async" breaks that assumption. That's not true at all. Here is a simple NodeJS implementation that is completely unsafe despite having non-transparent async: function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } async function LoggerWrite(s) { await delay(Math.random() * 100); console.log(s); } async function ChargeAccount(account, cents) { let balance = account.balance; let newBalance = balance - cents; await LoggerWrite("changing account from "+ balance + " to " + newBalance); account.balance = newBalance; } async function Main() { let account = {balance: 0}; let t1 = ChargeAccount(account, 1); let t2 = ChargeAccount(account, 20); let t3 = ChargeAccount(account, 18); let t4 = ChargeAccount(account, 12); await Promise.all([t1, t2, t3, t4]); console.log(account); } Main() //will randomly end up with -1 or -12 or -18 or -20, instead of the expected -51 And here is a Go program that does the right thing even with transparent async: func LoggerWrite(s string) { <-time.After(100) //this means "block for 100 ms" fmt.Println(s) } func ChargeAccount(account *account, cents int) { balance := account.balance newBalance := balance - cents LoggerWrite(fmt.Sprintf("changing account from %d to %d", balance, newBalance)) account.balance = newBalance } func main() { account := account{balance: 0} ChargeAccount(&account, 1) ChargeAccount(&account, 20) ChargeAccount(&account, 18) ChargeAccount(&account, 12) fmt.Printf("%+v\n", account) } //will ultimately print -51 You can try these yourself: NodeJS: https://replit.com/talk/share/Async-race-condition/138001 https://replit.com/talk/share/Async-race-condition/138001 Go: https://play.golang.org/p/ypKfQFUF5M2 https://play.golang.org/p/ypKfQFUF5M2 Edit: > Explicit async-await makes it more obvious that multiple invocations of ChargeAccount might interleave unless proven otherwise, and the programmer has a reason to confirm that it is not the case, or use locking / atomics as necessary. As shown by the example above, I think almost the opposite is true: async/await take code that looks linear and single-threaded and make it run concurrently. It's easy to accidentally end up with code like the JS one. Even worse, it's easy to accidentally call async code without await-ing it at all, and have unexpected behavior. By contrast, transparent async + cheap coroutines means that you can make all of your APIs blocking, and rely on the user explicitly spawning a coroutine if they want any kind of parallel/concurrent behavior, at the call site. In the Go code, I could have called `go ChargeAccount(...)` if I wanted the ChargeAccount calls to happen in parallel - I would have explicitly created parallelism, and I would have known to be careful of sharing the same pointer with the coroutines running concurrently.