Ok, so Robert said

The difference is how you wait, in the first case the thread is blocked till the operations complete. This is not so good as threads are expensive (by default on .NET each thread has a 1mb stack). In the second case no thread is blocked, only an object holding a callback is registered with the thread pool (which only costs a few bytes), the original thread is free to carry on doing other work and the end of the computation will be done by a thread from the thread pool.

The point being, threads are expensive, you want to create as few as possible.

Now suppose that 1000 copies of this async workflow are running in parallel, and suppose the thread pool has 10 threads to start, and suppose each IO call (Read or whatever) will block for 10ms (on disk or network or whatever; the exact numbers don't matter much). In the 'let' case (synchronous IO call), either

• we don't add any more threads to the thread pool, which means we start 10 reads, wait for them to complete, then start the next 10, wait, ... and end up taking more than a full second (1000 reads to do, 10 at a time, 10ms each = 1s) to do all this IO, most of the time with our CPU idle waiting, or
• we add threads to the threadpool to keep the CPU busy... but threads are expensive, and we just increased the memory footprint of our app (as well as some other overhead), and it's unclear how many threads you should add (trading off memory and other overhead to attempt to keep CPU busy)

Compare to the 'let!' case (async IO call):

• we start the first 10 (and release the thread after kicking off the read), then immediately start the next 10, etc, kicking off all the reads as fast as the CPU can go (but at most 10 BeginRead()s at a time, since just 10 threads), and probably get them all going before the first result even comes back
• as the calls return, free threads from the threadpool are used to process the results, each using only a few bytes in the queue on the IOCompletionPort between the time when the 'data is ready' and 'a thread is available to process the result' (invoking the EndRead() callback on a free thread).

The end result is our CPUs are always busy AND we have not had to create any extra threads. You can do all this with the existing async programming model (BeginFoo/EndFoo) but it is a huge pain to author that code and get it correct and the resultant code is always unreadable. With F#, all the goo is encapsulated and so you just change 'let' to 'let!' and 'Foo()' to 'FooAsync()' and you get the CPU/memory benefits of the async-style code with hardy any fuss.

Note that a line like

1

let! result = ReadAsync()

effectively means "on the current thread we are on prior to this line of code, kick off the read and schedule a callback to run the continuation of this workflow when the result arrives, and then release the current thread". So 'let!' does a little work and then lets go of the thread. Eventually something will call back, and so a (probably) new thread will run the continuation. You can see this happening by printing out the value of System.Threading.Thread.CurrentThread.ManagedThreadId before and after a 'let!'. In sum, this releases a thread and gets a (probably) new thread back, but while the long-running IO operation is pending, no thread is blocked, leaving that thread free to do other work rather than blocked and waiting.

Hi Bill, Your question seems closely related to a question I asked a while ago as well. That thread might help: [link:cs.hubfs.net] cheers, Kurt

Kurt

I took a look at the referenced thread and yes, it's almost exactly the question I have. From that thread I gather that a blocked thread is unavailable while an Async call releases the calling thread back to the thread pool. I can see the advantage there. What's misleading is that it's not the "Async-ness" that's buying you anything; rather it's the return of the thread to the pool. You're not speeding things up (assuming there are enough threads), but are conserving resources (that might cause that last assumption to become false.)

So, this is beginning to remind me of "cooperative multitasking" in the sense that the programmer has to know/understand this resource conservation technique. Having it presented in so many examples (having to do with performance improvements) without such an explanation must be causing confusion to more than just you and me!

Thanks for jumping in. The old thread helped a lot.

Bill

Robert,

I've thought further about your response. While it addresses the use of ASync forms of methods, I think I'm still confused about let! (!). Can your provide an example where using let! in association with an async form of method (e.g., ReadAsync) WOULD be appropriate?

If not, then why are let! and friends even in the language?

Bill

Yes, if you only have one operation to do then using you will pay a small overhead for using the asynchronous technique. This is because Async.Run will bloke the main thread and wait for the result. To take advantage of the async functionality you need to be in one of two case: 1) You don't care about result. In this case you can use Async.Spawn which will execute the task asynchronously, continue processing on the main thread and throw away the result. This is sometimes called the fire and forget model. 2) You have multiple operations you need to execute and you don't care about the execution order. You can compose the operations using Async.Parallel and then use Async.Run to collect a list of the result. In this case main thread will start and execute all the commands then bloke till all the results have been executed and processed by thread pool threads. Is that any clearer? Cheers, Rob

OK, that helps and is consistent with my assumptions. It's somewhat misleading how there are so many examples like the one I originally posted where use of let! seems inappropriate. Most of the async examples in _Expert F#_ have this characteristic for instance. While I realize these are somewhat pedantic, I would have expected some sort of disclaimer regarding the use of let! in order to avoid precisely the confusion I suffered!

Thanks again.

Bill