views:

304

answers:

6

I am trying to learn how async and let! work in F#. All the docs i've read seem confusing. What's the point of running an async block with Async.RunSynchronously? Is this async or sync? Looks like a contradiction.

The documentation says that Async.StartImmediate runs in the current thread. If it runs in the same thread, it doesn't look very asynchronous to me... Or maybe asyncs are more like coroutines rather than threads. If so, when do they yield back an forth?

Quoting MS docs:

The line of code that uses let! starts the computation, and then the thread is suspended until the result is available, at which point execution continues.

If the thread waits for the result, why should i use it? Looks like plain old function call.

And what does Async.Parallel do? It receives a sequence of Async<'T>. Why not a sequence of plain functions to be executed in parallel?

I think i'm missing something very basic here. I guess after i understand that, all the documentation and samples will start making sense.

+3  A: 

The usage of async is to save the number of threads in usage.

See the following example:

let fetchUrlSync url = 
    let req = WebRequest.Create(Uri url)
    use resp = req.GetResponse()
    use stream = resp.GetResponseStream()
    use reader = new StreamReader(stream)
    let contents = reader.ReadToEnd()
    contents 

let sites = ["http://www.bing.com";
             "http://www.google.com";
             "http://www.yahoo.com";
             "http://www.search.com"]

// execute the fetchUrlSync function in parallel 
let pagesSync = sites |> PSeq.map fetchUrlSync  |> PSeq.toList

The above code is what you want to do: define a function and execute in parallel. So why do we need async here?

Let's consider something big. E.g. if the number of sites is not 4, but say, 10,000! Then There needs 10,000 threads to run them in parallel, which is a huge resource cost.

While in async:

let fetchUrlAsync url =
    async { let req =  WebRequest.Create(Uri url)
            use! resp = req.AsyncGetResponse()
            use stream = resp.GetResponseStream()
            use reader = new StreamReader(stream)
            let contents = reader.ReadToEnd()
            return contents }
let pagesAsync = sites |> Seq.map fetchUrlAsync |> Async.Parallel |> Async.RunSynchronously

When the code is in use! resp = req.AsyncGetResponse(), the current thread is given up and its resource could be used for other purposes. If the response comes back in 1 second, then your thread could use this 1 second to process other stuff. Otherwise the thread is blocked, wasting thread resource for 1 second.

So even your are downloading 10000 web pages in parallel in an asynchronous way, the number of threads are limited to a small number.

I think you are not a .Net/C# programmer. The async tutorial usually assumes that one knows .Net and how to program asynchronous IO in C#(a lot of code). The magic of Async construct in F# is not for parallel. Because simple parallel could be realized by other constructs, e.g. ParallelFor in the .Net parallel extension. However, the asynchronous IO is more complex, as you see the thread gives up its execution, when the IO finishes, the IO needs to wake up its parent thread. This is where async magic is used for: in several lines of concise code, you can do very complex control.

Yin Zhu
I don't think you answered the right question.
Gabe
I think I am correct. I started with his question "Why not a sequence of plain functions to be executed in parallel?". So I predict that he is new to .Net, thus needs to see the motivation of async IO.
Yin Zhu
There is a difference between being new to .NET and the Parallel Framework extension library, and this question is more of the latter.
James Black
Yes, i'm not a .NET programmer.The sentence below clears up a lot of things, thanks:[[When the code is in use! resp = req.AsyncGetResponse(), the current thread is given up and its resource could be used for other purposes]]So you can't say: "after `use! resp = req.AsyncGetResponse()`, control returns to {the-caller|somewhere-else} until the response is ready", because it could go anywhere, right?In the line `use! resp = req.AsyncGetResponse()`, what exactly does _the magic_? Is it `use!` alone or the `Async*` method has some special property?Thanks for the answers, keep them coming.
marcus
Replying to myself: After some reading, i found out that AsyncGetResponse returns an Async<WebResponse> object and then `use!` runs it.There are a lot of things going on! A list of sites which becomes a list of Async objects (which create another Async object for each call to AsyncGetResponse) and then the list is passed to Async.Parallel which returns a new Async object that is run, using Async.RunSynchronously! Wow, that's hard.
marcus
A: 

The idea behind let! and Async.RunSynchronously is that sometimes you have an asynchronous activity that you need the results of before you can continue. For example, the "download a web page" function may not have a synchronous equivalent, so you need some way to run it synchronously. Or if you have an Async.Parallel, you may have hundreds of tasks all happening concurrently, but you want them all to complete before continuing.

As far as I can tell, the reason you would use Async.StartImmediate is that you have some computation that you need to run on the current thread (perhaps a UI thread) without blocking it. Does it use coroutines? I guess you could call it that, although there isn't a general coroutine mechanism in .Net.

So why does Async.Parallel require a sequence of Async<'T>? Probably because it's a way of composing Async<'T> objects. You could easily create your own abstraction that works with just plain functions (or a combination of plain functions and Asyncs, but it would just be a convenience function.

Gabe
A: 

In an async block you can have some synchronous and some async operations, so, for example, you may have a web site that will show the status of the user in several ways, so you may show if they have bills that are due shortly, birthdays coming up and homework due. None of these are in the same database, so your application will make three separate calls. You may want to make the calls in parallel, so that when the slowest one is done, you can put the results together and display it, so, the end result will be that the display is based on the slowest. You don't care about the order that these come back, you just want to know when all three are received.

To finish my example, you may then want to synchronously do the work to create the UI to show this information. So, at the end, you wanted this data fetched and the UI displayed, the parts where order doesn't matter is done in parallel, and where order matters can be done in a synchronous fashion.

You can do these as three threads, but then you have to keep track and unpause the original thread when the third one is finished, but it is more work, it is easier to have the .NET framework take care of this.

James Black
+3  A: 

A few things.

First, the difference between

let resp = req.GetResponse()

and

let! resp = req.AsyncGetReponse()

is that for the probably hundreds of milliseconds (an eternity to the CPU) where the web request is 'at sea', the former is using one thread (blocked on I/O), whereas the latter is using zero threads. This is the most common 'win' for async: you can write non-blocking I/O that doesn't waste any threads waiting for hard disks to spin around or network requests to return. (Unlike most other languages, you aren't forced to do inversion of control and factor things into callbacks.)

Second, Async.StartImmediate will start an async on the current thread. A typical use is with a GUI, you have some GUI app that wants to e.g. update the UI (e.g. to say "loading..." somewhere), and then do some background work (load something off disk or whatever), and then return to the foreground UI thread to update the UI when completed ("done!"). StartImmediate enables an async to update the UI at the start of the operation and to capture the SynchronizationContext so that at the end of the operation is can return to the GUI to do a final update of the UI.

Next, Async.RunSynchronously is rarely used (one thesis is that you call it at most once in any app). In the limit, if you wrote your entire program async, then in the "main" method you would call RunSynchronously to run the program and wait for the result (e.g. to print out the result in a console app). This does block a thread, so it is typically only useful at the very 'top' of the async portion of your program, on the boundary back with synch stuff. (The more advanced user may prefer StartWithContinuations - RunSynchronously is kinda the "easy hack" to get from async back to sync.)

Finally, Async.Parallel does fork-join parallelism. You could write a similar function that just takes functions rather than asyncs (like stuff in the TPL), but the typical sweet spot in F# is parallel I/O-bound computations, which are already async objects, so this is the most commonly useful signature. (For CPU-bound parallelism, you could use asyncs, but you could also use TPL just as well.)

Brian
Thanks! Serching for key terms you mentioned in your post, i foundhere http://blogs.msdn.com/b/dsyme/archive/2009/10/19/release-notes-for-the-f-october-2009-release.aspx that some operations have an "automatic return to context", so GUI operations as easier to implement. But if the programmer is unaware of this feature, it gets very confusing, because at first sight the code seem to be broken and yet it works.
marcus
Yes, there's definitely a trade-off here between convenience in the common case and overall perspicacity/transparency of the code/threading model.
Brian
+2  A: 

Recently I've made a brief overview of functions in Async module:here. Maybe it will help.

desco
Very helpful, thanks! But it will take me some time to fully understand all of that! :-)
marcus
A: 

Here is a code sample utilizing asynchronous workflows:

How to download stock quotes from Google Finance with F#

Koistya Navin