4 ms·

This problem can also easily happen with async code, if you have any shared state with the async code, especially if you are running multiple async calls in par

This problem can also easily happen with async code, if you have any shared state with the async code, especially if you are running multiple async calls in parallel. It can even happen in single-threaded runtimes like Node, where people are even less likely to expect it.

Arnavion 6y ago
My point is that "transparent async" code can lull the programmer into a false sense of security. Contrived example: void ChargeAccount(Account account, int cents) { int balance = account.balance; int newBalance = balance - cents; Logger.Write("changing account from {balance} to {newBalance}"); account.balance = newBalance; } This works fine because it's all synchronous code. Then someone classloads a Logger implementation that's "transparent async" because it logs to a network sink in addition to synchronous stderr, and now there's a chance two calls to ChargeAccount interleave and one of the charges is lost. If it's explicitly async with async-await keywords etc, then the race is easily noticeable and the programmer will know they have to use a mutex or atomics or whatever.
- simiones 6y ago
  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

Arnavion 6y ago

My point is that "transparent async" code can lull the programmer into a false sense of security. Contrived example: void ChargeAccount(Account account, int cents) { int balance = account.balance; int newBalance = balance - cents; Logger.Write("changing account from {balance} to {newBalance}"); account.balance = newBalance; } This works fine because it's all synchronous code. Then someone classloads a Logger implementation that's "transparent async" because it logs to a network sink in addition to synchronous stderr, and now there's a chance two calls to ChargeAccount interleave and one of the charges is lost. If it's explicitly async with async-await keywords etc, then the race is easily noticeable and the programmer will know they have to use a mutex or atomics or whatever.

simiones 6y ago
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