]]>https://blogs.msdn.microsoft.com/gordonhogenson/2014/06/02/installing-azure-sdk-2-3-for-visual-studio-14-ctp/feed/2Using MailboxProcessor.Scan for communication between F# agentshttps://blogs.msdn.microsoft.com/gordonhogenson/2011/01/20/using-mailboxprocessor-scan-for-communication-between-f-agents/
https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/20/using-mailboxprocessor-scan-for-communication-between-f-agents/#respondThu, 20 Jan 2011 18:14:00 +0000https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/20/using-mailboxprocessor-scan-for-communication-between-f-agents/In a previous post, I presented a background job manager in F# using the MailboxProcessor. In this post, I’ll try to keep the number of background jobs equal to the number of processors on the machine. The number of processors that is meaningful here is the number of CPUs in the machine times the number of cores in each CPU. On my system, there are only two, but newer or more high-end machines have many cores, perhaps 4, 8, or 16.

With these advances in hardware, obviously you want to make as efficient use as possible of all the cores on the machine. Let’s imagine that you have a series of long computations to do, and you want to maximize the use of CPU. One way to do this is to use F# agents, namely the MailboxProcessor class, to manage these computations as jobs. An F# agent is something that processes messages in a queue.

To manage these background jobs, I created an F# agent called controllerAgent that accepts requests for jobs to be run. I then created an array of agents equal to the number of processors on the machine. The .NET Framework provides the property Environment.ProcessorCount which conveniently gives you this.

In this example, the computation is one I used in a previous blog entry, computing the Nth prime number. You will no doubt be able to come up with a more efficient algorithm for doing this (such as this one by Jon Harrop), but since I’m just trying to show how to run a computation and view its result, this will do fine.

In this example, the array of agents that represent each processor is called execAgents. Initially, I created it as an array of nulls. This is because its initialization code uses the controllerAgent. What I have here are mutually self-referential entities. In F#, definitions of a value must precede the use of the value. By defining the execAgents array first, I can reference it in the initialization code for controllerAgent.

In previous blog posts, I used Receive to process each message. In this example, I use Scan. Scan allows me to look through the queue for the appropriate type of message. The standard use of Scan is with cooperative agents. Agent A is processing messages, but needs some help from agent B, so it sends a message to agent B. Agent B replies, and agent A uses Scan to find the reply. In this example, the controllerAgent processes the messages and signals the execAgent to start a job, but if all the execAgents are busy, it waits for a message from an execAgent saying it has completed a job.

// Assume we have n processors on a machine and always want 1 job running per processor.

// A set of agents represent processors, which can be either busy or idle.

// The controller accepts requests and assigns the job to one of the processor queues.

// The main processor keeps track of whether each node is busy or idle. If one is idle,

// the job is assigned immediately. If there is no idle processor, the message box is scanned

]]>https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/20/using-mailboxprocessor-scan-for-communication-between-f-agents/feed/0Using F# agents and cancellation tokens to manage background jobshttps://blogs.msdn.microsoft.com/gordonhogenson/2011/01/14/using-f-agents-and-cancellation-tokens-to-manage-background-jobs/
https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/14/using-f-agents-and-cancellation-tokens-to-manage-background-jobs/#commentsFri, 14 Jan 2011 14:21:00 +0000https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/14/using-f-agents-and-cancellation-tokens-to-manage-background-jobs/In a previous post, I created an F# agent that runs background computations. However, it was limited in that it allowed the user no control over the jobs. Really, I want a more flexible system that allows the user to cancel currently running jobs. To implement this, I used F# agents (the MailboxProcessor class) to start jobs and to process when jobs finish. I implemented cancellation by keeping a collection of running jobs and using cancellation tokens, a .NET Framework 4.0 feature.

I created a JobState discriminated union to represent whether a job is not started, running, canceled or completed.

// The state of the job.

type JobState =

| NotStarted

| Running

| Canceled

| Completed

I created a Job type that is a record. It includes a cancellation token, an asynchronous computation, and state information.

// a Job consists of a job ID, a computation, a cancellation token source,

// and a state.

type Job = {

id : int

comp : Async<Result>

token : CancellationToken

state : JobState

}

The function to create the jobs themselves is still creating mock jobs. The job is represented by an asynchronous workflow, which sleeps for a while. But instead of one call to Sleep, it calls Sleep in a loop for a short time. At each appearance of a let!, do!, or other ! keyword (in this case, each invocation of Async.Sleep), F# checks for cancellation automatically. You do not have to monitor the value of IsCancellationRequsted. In this case, the loop is terminated when cancellation occurs, and if you started the job with Async.StartWithContinuations, then the cancellation continuation is called.

// Generates mock jobs using Async.Sleep

let createJob(id:int, token:CancellationToken) =

let job = async {

// Let the time be a random number between 1 and 10000

// And the mock computed result is a floating point value

let time = random.Next(10000)

let result = 2.0 + random.NextDouble()

let count = ref 0

// Start child jobs

while (!count <= 100) do

do! Async.Sleep(time / 100)

count := !count + 1

return result

}

{ id = id; comp = job; token = token; state = JobState.NotStarted }

Cancellation is supported by the .NET Framework 4.0 and involved when you use cancellation tokens. There are a few classes involved when using cancellation tokens. One class, CancellationTokenSource, creates a CancellationToken, which is just an identification of what you want to cancel. Each of these background jobs will be represented by an asynchronous work item and those work items will have an associated CancellationToken. The cancellation token is passed in as an optional argument when you start the jobs in the call to StartWithContinuations.

Cancellation tokens are really useful when you have multiple jobs that depend on each other, and you want to cancel all related jobs at once, so this example adds the ability to create child jobs. The child jobs all share the same cancellation token as a parent job, so they are cancelled when the parent job is cancelled.

Initially, I introduced a global mutable array (called jobs) to store information, including the job state, which indicates whether the job is running, canceled, etc. But, a global mutable value needs to have synchronized access since there are multiple threads writing to it. You can use F# agents to synchronize access to global mutable state such as a shared collection. I decided to try that in my job collection. Instead of modifying the array directly, I created the type JobCollection, and then I created an agent that is internal to this class, and I wrote a public indexed property whose setter posts to that agent when I modify the array.

There are three different arrays in JobCollection: one for the jobs, one for the token sources, and one for the parentIds, which is only relevant for child jobs. They should all have the same length. I could have certainly decided to put some of this in the Job type itself, but in this implementation, it’s the JobCollection’s responsibility to manage parent/child relationships and make sure that the tokens in each Job come from the right token source.

You could also use a lock to enforce synchronized access, as I did in the JobCollection method AddChildJobs. This method locks the collection in order to make modifications to the internal arrays. In a more serious implementation, it might be good to compare the performance of managed synchronized access using a lock to that of using a MailboxProcessor.

I created two agents that manage the jobs. One of the agents is called runAgent and it starts the jobs by calling Async.StartWithContinuations. In the call to StartWithContinuations, which is highlighted in green in the code, I specify the code I want to run when the job completes. In this case, the code posts a message to another agent called completeAgent, as well as the code I want to run when the job is canceled. The second argument is the exception continuation, which is not used.

printAgent.Post <| “Specify a job by number to cancel it, and then press Enter.”

letmutable finished = false

while not finished do

let input = System.Console.ReadLine()

let a = ref 0

if (Int32.TryParse(input, a) = true) then

cancelJob(!a)

else

printAgent.Post <| “Closing.”

finished <- true

Here is an example session that shows that job #2 has four children, and that if you cancel job #2, all the child jobs are cancelled also.

Specify a job by number to cancel it, and then press Enter.Starting job #0Starting job #1Starting job #2Starting job #3Starting job #4Starting job #5Starting job #6Starting job #7Starting job #8Starting job #9Starting job #10 with parentId #2Starting job #11 with parentId #2Starting job #12 with parentId #2Starting job #13 with parentId #22Cancelling job #2Canceled job #13Canceled job #2Canceled job #11Canceled job #10Canceled job #12The result of job #3 is 2.801492The result of job #0 is 2.164704The result of job #7 is 2.930089The result of job #5 is 2.191637The result of job #6 is 2.558175The result of job #1 is 2.398534The result of job #8 is 2.462594The result of job #9 is 2.575942The result of job #4 is 2.051622

In the next post, we’ll look at utilizing multiple CPU cores by limiting the number of running jobs to be equal to the number of processors available.

Gordon

]]>https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/14/using-f-agents-and-cancellation-tokens-to-manage-background-jobs/feed/4Using F# agents to manage background jobshttps://blogs.msdn.microsoft.com/gordonhogenson/2011/01/12/using-f-agents-to-manage-background-jobs/
https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/12/using-f-agents-to-manage-background-jobs/#respondWed, 12 Jan 2011 18:23:00 +0000https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/12/using-f-agents-to-manage-background-jobs/In a previous post, I started out with some simple F# agents. As we saw previously, agents process messages in a queue and perform actions in response. In the previous post, I created a simple console application that starts an agent, and then starts a loop that reads each line of input from the console and submits it to the agent. The intention is to build up the code to produce a small console app that I can use to launch and control background jobs. The first change from the previous code is to allow multiple messages to be sent before waiting for a reply on the reply channel. This means that instead of using PostAndReply to send a message to the agent, I need to use PostAndAsyncReply. Just changing the function changes the return value so that now an asynchronous workflow object (in this case Async<Message>) is returned. I need to start this. I have several options. Just to get started, let’s just run the workflow by using Async.RunSynchronously. This results in code that is pretty much equivalent to PostAndReply, since the asynchronous workflow is only being used in a synchronous way. The code will still block waiting for the reply to each job before enabling you to start another one.

I can think of two other options. I could start it as a task by using Async.StartAsTask. StartAsTask launches a .NET Framework Task and then returns control immediately, so it is asynchronous. The return value is a Task object, and so I could start a number of tasks and maintain a collection of the tasks that are currently running, and track them when they complete. Here is what the code looks like using tasks:

I think it actually is simpler to just use Async.StartWithContinuations. Instead of having to manage a Task object, I can just specify the code I want to run when the reply is available. This is referred to as a continuation function, and I can just specify this function as a lambda expression in the arguments to Async.StartWithContinuations. I really like Async.StartWithContinuations. Being able to specify code to run later in a simple lambda expression seems pretty powerful. There are actually three different continuation functions that Async.StartWithContinuations accepts. The first is the code to run when a result is available. The second is the code to run when an exception occurs, and the third is the code to run when an operation is canceled. In this case, we’re only using the first one. Next time we’ll look at using the cancellation continuation. The exception continuation won’t be used in these examples, because the mailbox processor has a different mechanism for transmitting exceptions, using the Error event, which I showed at the end of the previous blog post.

I’ll also add some code to delay when the messages return, so it is more obvious that this is working asynchronously, and because I expect the jobs to do that when I write my job agent.

OK. So now that I have figured out the basic mechanics, I am ready to write my job agent. I’m going to start with a mock job, which is just going to sleep for a random amount of time. I have added a createJob function that takes a job ID and creates a simulated job. I’m going to submit this job instead of the string as the Message, and I’m going to change the reply to include the result of the job and its ID. To actually start the job, I’m going to use StartWithContinuations within the message loop and the reply is going to be sent in the continuation. That way all the jobs start at once, but the replies come in a staggered fashion as the jobs finish.

module JobAgent =

open System

let random = System.Random()

// Generates mock jobs using Async.Sleep.

let createJob(id:int) =

let job = async {

// Let the time be a random number between 1 and 10000,

// and the mock computed result is a floating point value.

let time = random.Next(10000)

let result = random.NextDouble()

do! Async.Sleep(time)

return result

}

id, job

type Result = double

// a Job consists of a job ID, and a computation that produces a single result.

Now let’s actually calculate something interesting. The code changes slightly, since now we’re taking a lambda for the function to run to compute a result. Also, the result is going to be a generic quantity. I want the generic type to be inferred, so I’m going to use the wildcard character (_) in one place where I would normally have to put in the exact type. In this case, the result type is going to be BigInteger, since we’re computing the Nth prime numbers. There are definitely more efficient ways of computing prime numbers, but the main point here is to demonstrate running a computation, not to optimize that calculation.

module JobAgent =

open System

let random = System.Random()

// Generates mock jobs using Async.Sleep.

let createJob(id:int, computation, input : int) =

let job = async {

// Let the time be a random number between 1 and 10000,

// and the mock computed result is a floating point value.

let time = random.Next(10000)

let result = computation(input)

return result

}

id, job

// a Job consists of a job ID, a computation that produces a single result.

That’s all for now. Next time, instead of using the reply channel to communicate back to the thread that posts the messages, I’ll use multiple agents (one for job requests, one for running jobs, and one for completion notifications) and we’ll look at how to get the currently running jobs and how to cancel jobs. I was impatient, so I set the multiplier for N to be only 1000. You could try copying this code and changing that number to a larger one.

Gordon

]]>https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/12/using-f-agents-to-manage-background-jobs/feed/0F# agents with timeoutshttps://blogs.msdn.microsoft.com/gordonhogenson/2011/01/10/f-agents-with-timeouts/
https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/10/f-agents-with-timeouts/#commentsMon, 10 Jan 2011 16:52:00 +0000https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/10/f-agents-with-timeouts/In my previous post, I showed a code snippet with a very simple F# agent console application. You run the app from the console, and every time you enter a line of text, it generates a new message and posts it to the message queue of an F# agent. An agent is an instance of the MailboxProcessor class. The MailboxProcessor is a class in the F# core library in the Control namespace. As the name MailboxProcessor implies, an agent is something that you can send messages to, and it runs some code in response to messages that you send. The code that it runs is conveniently expressed as a lambda expression that you pass in.

Typically the lambda expressions that you pass in will all follow a common pattern, which is a loop that repeatedly takes a message from the queue, one at a time. You call the Receive method on each iteration of the loop.

Here is the sample code that I posted the other day. In this code, we create one agent and its message-processing loop as I’ve just described. Additionally, we run a loop that reads one line at a time from the console and sends each line to the agent. If you run this program, then every time you enter some text, the text is received as a message. In addition to the basic message processing, this example shows how to send information back to the caller by using the reply channel, an object of type AsyncReplyChannel. The only processing that happens in this simple example is that if the message is “Stop” then send a special reply, otherwise send a reply that we’ve received a message, along with the ID and text of the message.

The other interesting thing is the async { … } in the message processing loop. Asynchronous programming is one of the strengths of F#. MailboxProcessor is designed to work asynchronously. So, for example, the return type of the lambda expression is Async<unit>, an asynchronous work item. This allows us to start to listen to messages but not block on waiting for the next message. The use of let! instead of let, and do! instead of do indicates an asynchronous operation. The basic idea is that execution goes up until a let! or do! and then, if no return or completion is ready, execution can go on elsewhere. Then, when a return value is available, or the execution is complete, then the program continues from that point. Behind the scenes, a callback is used and the remaining code after the let! or do! is packaged up into the callback. Obviously all of that is rather complicated, so what people like about the design is that you can write asynchronous code much as you would write synchronous code, with a few extra bangs (!) here and there, and F# asynchronous workflows take care of making it asynchronous.

The asynchronous feature of F# is one of its most attractive features. In fact, it was so nicely done that it is being implemented in C# and Visual Basic as well, and you can try that out in a CTP release that came out in the fall of 2010 at the PDC conference. It can seem a bit like a black box though. One thing I hope to do in this series of blog posts is to explore the asynchronous programming model and hopefully elucidate this black box. In particular, we want to have a mental model of how to think about how it operates. It would be one thing if all it did was fire up a background thread every time a new logical “program flow” came into play. In this example, we have two loops going, one that reads input, and one that processes messages. You would think that there are two threads going on in parallel since there are these two loops happening “at the same time”. Let’s test this theory by printing out the Thread ID.

Then add some code that calls this printThreadId method, with either an argument of “MailboxProcessor” or “Console”. If you run this, you’ll find that indeed it is true, the MailboxProcessor loop is running on separate threads from the UI thread that is reading from the console. I found when running this that there were in fact two background threads reading messages from the queue. Here is the code after adding these changes:

Let’s suppose we want to now add some timeout condition, so that after a while of no new input from the console, the app posts a note saying that a timeout occurred and skips to the next message ID. Receive takes a timeout as an optional argument, which is an integer in milleseconds. I set a timeout of 10 seconds. If the timeout is exceeded, TimeoutException is thrown. I want to catch this exception, but at first, I tried to put the try/with outside the call to PostAndReply. But, the exception was never caught! I can only catch the exception on the same thread where it is generated, so the exception handler has to be in the mailbox processor message loop. I also had to be careful to start the next loop iteration in the case of a timeout. Ouch, I got a bit caught by the fact that F# asynchronous workflows are so smooth, I don’t even know I’m running on a separate thread. Here is an implementation of the timeout that works.

However there are definitely times when you want the exception to be propagated to the thread that posted the message. It is possible to do this, with the Error event. The Error event takes a lambda expression that processes an exception. Here is an example where the agent throws a timeout exception and it is handled by the Error event.

module MailboxProcessorWithError =

open System

type Message = string

let agent = MailboxProcessor<Message>.Start(fun inbox ->

letrec loop n =

async {

let! message = inbox.Receive(10000);

printfn “Message number %d. Message contents: %s” n message

do! loop (n+1)

}

loop 0)

agent.Error.Add(fun exn ->

match exn with

| System.TimeoutException as exn -> printfn “The agent timed out.”

printfn “Press Enter to close the program.”

Console.ReadLine() |> ignore

exit(1)

| _ -> printfn “Unknown exception.”)

printfn “Mailbox Processor Test”

printfn “Type some text and press Enter to submit a message.”

whiletruedo

Console.ReadLine() |> agent.Post

Where I’m headed with this, is I want to create a job agent that will allow me to start some background jobs from a command prompt. The timeout isn’t really necessary, but it did help clarify the behavior of exceptions that take place in the message loop. If I want to start jobs in the background, I’m going to want to start up multiple jobs at a time, so it won’t do to submit one message and then have to wait until PostAndReply returns! I will need to use PostAndAsyncReply, so in the next version, both the message processing loop and the input loop will be asynchronous.

Gordon

]]>https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/10/f-agents-with-timeouts/feed/1Welcome to Gordon Hogenson’s F# Bloghttps://blogs.msdn.microsoft.com/gordonhogenson/2011/01/06/welcome-to-gordon-hogensons-f-blog/
https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/06/welcome-to-gordon-hogensons-f-blog/#commentsThu, 06 Jan 2011 13:09:00 +0000https://blogs.msdn.microsoft.com/gordonhogenson/2011/01/06/welcome-to-gordon-hogensons-f-blog/I’m the technical writer who wrote most of the MSDN documentation for F#, and I decided to start a less formal channel of communication to share some of what I’m learning about F# and associated technologies.

But first a few notes about how to let me know about problems and other feedback for the F# MSDN docs. First to clarify what I actually am responsible for. Anything with an address that includes msdn.microsoft.com/library and is related to F#, I am interested in hearing feedback on. In terms of the specific table of contents areas in the MSDN TOC, that is anything under this node: http://msdn.microsoft.com/en-us/library/dd233154.aspx. The feedback link is harder to find in MSDN’s lightweight view, but it is there at the very bottom of the page. Any comments you put into the feedback box will make it to me, unless it gets caught up in the spam filter, which it shouldn’t unless you are using the feedback link to advance your Viagra business.

One of the things that this blog will include is lots of F# programs! In the course of my responsibilities, I often write small pieces of code, and sometimes larger projects. Much of this is an effort to explore the ins and out of some particular aspect of the F# language and the F# core library. For example, over the past year, I’ve written some examples using F#’s asynchronous workflows, the F# MailboxProcessor, and the like.

The other thing that I’m interested in is the transition from other languages, like C++ and C#, to F#. As a C++ and C# programmer, I am familiar with a certain paradigm of computing, but I also was vaguely familiar with the idea of functional programming. Over the last several years, I’ve had the opportunity to explore the functional programming paradigm, and I’m interested in how this changes the way we think about solving everyday programming problems and how this way of thinking might improve how I design new APIs. For example, how do I code without using mutable variables? And maybe more importantly, when is it beneficial to code without mutable variables, and when is it being too pedantic?

And then there are the larger software engineering questions, such as, can adopting a functional approach improve the ability of a team to deliver great products? The promise of functional programming of greatest interest to those who run software businesses is that it makes it easier to write code that is stable and is easier to maintain. One of the larger things that we at Microsoft are learning in embracing a functional language like F# is how using this type of programming can benefit our industry.

To get us warmed up, I’ll say that I’ve been looking at the MailboxProcessor lately. The F# MailboxProcessor provides a message-passing mechanism that allows you to structure a program as a set of agents which read and respond to a queue of messages. In some ways it is akin to MSMQ, but its inspiration comes from the language Erlang, which is specifically designed to be an agent-based language. F# is not specifically designed for agent-based programming, but the MailboxProcessor provides support for this type of programming.

For example here is a program I wrote recently that starts up a MailboxProcessor. The code defines an agent that runs a loop that reads messages. Here, the message is just a string read from the console window, paired with a reply channel. The agent reads each message and then submits a reply through a reply channel that is passed in. The reply is then printed, or if the special “Stop” command is given by the user, the loop ends.

One thing I try to do in the documentation is demonstrate how to use functional programming style. Functional programming purists might prefer to rewrite the loop as a recursive function, and eliminate the mutable control variable.

But as a practical person, I now worry, will my recursive function create a stack frame for every iteration, or is F# going to be smart and just reuse the same stack frame for it? If I was confident enough in my knowledge of tail recursion and the F# compiler’s tail recursion features, I could deduce all this from the code, but then to be sure I might want to check empirically, so I fired up the debugger and set a breakpoint in the loop, then went through a few iterations on input. In fact, the call stack window shows that there is only one stack frame that is shared for each recursive call. Great, now I know this “functional” form of my code won’t blow up the stack.

That’s it for today, but clearly the code could be improved. What about adding a timeout and handling what happens then? In the next installment, I will look at how to do this.