LA.NET [EN]

Multithreading: a final example on how CompareExchange might help you

luisabreu — Sat, 04 Jul 2009 15:31:44 GMT

In the last posts we’ve been poking around memory models, memory fences and other interesting things that might lead to the so called lock free programming. Before keep looking at how we can use those features from our C# code, I’d like to add one more example that shows how the interlocked operations might help you in the real world. Do you recall our implementation of the IAsyncResult interface?

At the time, we’ve used a lock for ensuring proper access and initialization of our manual reset event used for signaling the end of the operation. Now that we’ve met interlocked operations, we can improve that code and get rid of the lock. Let’s focus on the private GetEvtHandle method:

private ManualResetEvent GetEvtHandle() {
  var newEvt = new ManualResetEvent(false);
  if (Interlocked.CompareExchange(ref _evt, newEvt, null) != null) {
    newEvt.Close();
  }      
  if (_isCompleted) {
    _evt.Set();
  }      
  return _evt;
}

As you can see, we’ve replaced the lock with a CompareExchange method call for ensuring proper atomic update: if the _evt field is null, then set it to newEvt (which, if you recall our previous post on interlocked operations, will only happen when that value is null!). Since the method returns the old value, if we get anything different from null, then it means that some other thread already set the field to a valid value. When that happens, we need to clean up and close the manual reset event we’ve just created. And there you go: the lock is gone.

As you’ve probably guessed, This strategy can be adjusted to objects that implement the IDisposable interface and you can use it when the creation of new objects isn’t too expensive and you need to have only a single instance of an item (in other words, it might be a valid option for implementing singletons in multithreading scenarios).

And that’s it. Keep tuned for more on multithreading.

Multithreading: using fences from .NET code

luisabreu — Fri, 03 Jul 2009 14:28:13 GMT

In the last post, we’ve talked about memory fences. Today we’re going to keep looking at this topic, but we’re turning our attention to coding, ie, we’re going to talk about the options we have to add fences to our classes. In .NET, things are relatively straightforward.

Whenever we use one of the interlocked methods we’ve met in the past, we’re adding a full fence to our code. Locking will also end up using full fences. As you can see, you’re already using full fences in several places. The good news is that you can also be specific about them, ie, there’s a method you can call if you want to add a fence to your code in a specific place: I’m talking about the Thread.MemoryBarrier static method (btw, this method will also add a full fence).

Volatile reads or writes generate fences too! In C#, you can use the volatile keyword to mark a field as volatile. Reading a volatile field is the “equivalent” of having an acquiring fence. Writing to a volatile field can be seen as “adding” a release fence. Now, it’s important to notice that you’ll always get these read and write behaviors whenever you use the volatile field. If you’re looking for more control (ex.: you’ll only interested in having an acquire fence for a read), then you should rely on the Thread.VolatileRead or Thread.VolatileWrite methods for ensuring proper the desired behavior.

And I guess that’s all there’s time for today. In the next post, we’ll keep looking at multithreading and see how we can use these features on a C# program. Keep tuned!

Multithreading: introducing memory fences

luisabreu — Fri, 03 Jul 2009 12:58:22 GMT

A few posts back, we’ve introduced the concept of load and store reordering. As we’ve seen, reordering operations exist as a way of improving performance and can be introduced on several levels (starting at compilation time and ending at runtime when the processor executes the instructions). We saw that even though things can get chaotic quickly, there are some guarantees we can hold on to when writing multithreaded code. One of those guarantees is that all platforms respect a specific memory model and that’s what we’ll be talking about in this post.

A memory model defines which kinds of moves may occur (ie, which loads and stores can be moved). If you’ve got a weak memory model, then you’ll get plenty of allowable moves and this will lead to a superior performance. However, you’ll also need to pay lots of attention to the code you write. Allowing less moves will, of course, lead to less complexity but won’t give you (hum…I mean, the compiler and processor) that many chances for updating your code.

Since we’re talking about .NET here, we’ll focus the rest of the post on the valid assumptions for the CLR. The CLR has a strong memory model. In practice, this means that several compiler optimizations are forbidden and that it should be fairly easy (sort of…) to write code that is portable across several architectures where the code might run. Before going on, it’s important to notice that the CLR memory model is tighter than the one you get in the ECMA spec.

In the CLR, you can get reordering for load/load, load/store and store/load. The only one which isn’t permitted is store/store reordering (meaning that a store can never move after another store). Volatile loads and stores are different and only allow store/load reordering (we’ll be talking about volatiles in future posts). Btw, the ECMA specification allows all these move types.

Ok, so if those store and load reordering are allowed, how can we stopped them from happening? ah, glad you asked! We can use fences (or barriers) to ensure that they don’t occur at specific times.

A fence (aka barrier) prevents memory loads and stores reordering from happening. There are several types of fences. Full fences are probably the most known and used type. A full fence ensures that no load or stores moves across the fence (ie, no load or store before the fence can move after it nor any load or store placed after the fence may move before it).

Besides the ubiquitous full fence (which is available everywhere), there are other variations. With Store fences, no store can move over the fence (it’s ok for reorders to happen with loads). Load fences are similar, but in this case, only loads are “fixed”.

Finally, there’s also a couple of “one way” fences: acquire and release fences. Acquire fences ensures that no memory operation that happens after the fence can be moved before the fence. Release fences work the other way around: instructions defined after the fence may happen before the fence but no “pre-fence” instruction may happen after the fence.

As you might have guessed by now, fences load to a more sequential model which will, without any doubt, lead to a degradation of your application. This means that you should apply them carefully. Yes, we do need fences, but do keep in mind that using them will reduce the ability for reordering and improving the code you write.

By now, I guess that we’ve covered most of the theory around fences. You might be asking: how do I use fences in my .NET code. Good question, but we’ll leave the answer for the next post. Keep tuned for more on multithreading.

Multithreading: when interlocked operations aren’t enough

luisabreu — Thu, 02 Jul 2009 14:45:30 GMT

In the previous post, we’ve started looking at interlocked operations. As we’ve seen, interlocked operations are great at what they do but they won’t be usable in all scenarios (ie, don’t think that they’ll solve all your locks problems). To show how things might go awry when using interlocks, I’ll reuse a great example written by Raymond Chen a few years ago (I’m updating it to C#):

class Program 
{
  private static Object _lock = new Object();
  public static Int64 InterlockedMultiply(
          ref Int64 multiplicand, Int64 multiplier) {
    Int64 result = 0;
    lock (_lock) {
      var aux = multiplicand;
      Thread.Sleep(100);//oops!!!
      result = multiplicand = aux * multiplier;          
    }
    return result;
  }      
  static void Main(string[] args) {
      Int64 a = 5;
      new Thread(
         () => InterlockedMultiply(ref a, 5)).Start();
      new Thread(() => { 
              Thread.Sleep(50); 
              Interlocked.Increment(ref a); }).Start();
      Thread.Sleep(2000);
      Console.WriteLine(a);
  }
}

The idea is to add a safe multiplier method. As we’ve seen in the previous post, interlocked increments are atomic. That means that they’re executed as a “single” operation by the processor. Since we didn’t had a method that performs the same operation for multiplication, we’ve decided to mimic that behavior by adding a new method which uses a lock to ensure proper multiplication.

If I asked you what Console.WriteLine(a) would print, what would you say? For now, forget those nasty Sleep invocations (they’re there to force the wrong behavior)… I’m guessing that you’d probably say that Console.WriteLine will only write 26 or 30. It will write 26 if InterlockedMultiply “beats” Increment or 30 if Increment is run before InterlockedMultiply. Ah, well, with those nasty sleep instructions, I’ve managed to get 25 here on my machine. Wtf? How? Why?

Well, what happened is logical…Interlocked.Increment will always update the value in a single atomic operation (this means it will load, update and then store the value in a “single” step). However, InterlockedMultiply only ensures that the code wrapped by the lock will only be executed by a thread at a time. Look at that method carefully…can you see a load followed by a store? Those two operations aren’t performed atomically like the one you get through the Interlocked.Increment method!

There is a solution to this problem, but it involves looping until you get a valid result. Take a look at the method updated to work correctly:

public static Int64 InterlockedMultiply(
       ref Int64 multiplicand, Int64 multiplier) {
  Int64 result = 0;
  Int64 aux = 0;
  do {
    aux = multiplicand;
    result = aux * multiplier;
  } while ( Interlocked.CompareExchange(
                ref multiplicand, result, aux) != aux);
  return result;
}

As you can see, we’re using the Interlocked.CompareExchange method to ensure that multiplicand will only be updated if it hasn’t changed during the execution of that loop. That happens because the Interlocked.CompareExchange method will always return the value that was stored in multiplicand at the time of the call (recall that CompareExchange always returns the original value of the 1st parameter passed to the method at the time of the call).

As you can see, interlocked operations don’t ensure proper serialization of your code. They only guarantee that the interlocked operation is done atomically. And I guess that’s all for now. Keep tuned for more on multithreading.

Multithreading: introducing the interlocked operations

luisabreu — Thu, 02 Jul 2009 11:58:04 GMT

As we’ve seen in the previous post, most processors give us important insurances regarding memory loads and stores. However, even though those insurances are important and can be used in several scenarios, the truth is that they aren’t enough for all real world tasks.

Fortunately, most processors also offer a group of interlocked operations which enable atomic compare and swap scenarios. These operations rely on hardware and interprocess synchronization. Notice that these operations aren’t as simply as they might seem at first sight. For instance, it’s important to recall that in today’s architectures, these kind of operations need to play well with caches. My point is that event though these operations tend to be cheaper that the traditional locks, they’re still not cheap (for instance, there are cases where an interlocked operation ends up locking the bus and that is not a good thing).

Currently, there are several kinds of interlocked operations. In .NET, all interlocked operations are exposed as members of the Interlocked class:

Add: adds two integers (int or long) and replaces the first with the value of the sum;
CompareAndExchange: compares two values and if they’re equal, replaces one of them with the other (notice that this method receives three parameters). This is probably the most important method of this class (it supports compares and exchanges on reference types two!);
Decrement: Similar to add, but in this case, it performs a subtraction;
Exchange: updates a variable with another value;
Increment: adds one to an existing variable;
Read: reads a value from a variable;

As I’ve said before, the advantage of using these methods is that all the operations are performed atomically. The Read method might not seen necessary at first until you look at its signature:

public static long Read(ref long location);

As you can see, it should only be used in 32 bits system when you need to access 64 bits integers. Atomically setting a value on 64 bits can be done through the Exchange method:

public static extern long Exchange(ref long location1, long value);

This means that you can easily build a generic write or read routine and reuse them across your programs:

public static class Generic64Helper {
  private const int WordSize32 = 4;
  public static void WriteLong(ref long location, long value) {
    if (IntPtr.Size == WordSize32) {
        Interlocked.Exchange(ref location, value);
    } else {
        location = value;
    }
  }
  public static long ReadLong(ref long location) {
    if (IntPtr.Size == WordSize32) {
        return Interlocked.Read(ref location);
    }
    return location;
  }
}

There a couple of interesting things going on here. First, we use the IntPtr.Size property to get the size of the “current” word. In 64 bits, we really don’t want to pay the price of the Interlocked operation and will simply delegate to a hardware atomic write or read. However, in 32 bits system (where the word size is 4), we really need to use those methods to have atomicity. Reusing this class is rather simple, as you can see from the next snippet (t is initialized with 10 and y is initialized with the value of t):

Generic64Helper.WriteLong(ref t, 10);
long y = Generic64Helper.ReadLong(ref t);

There a couple of gotchas with the previous approach (notice that only the read and write are atomics), but we’ll leave that for a future post. Now, the important thing is to concentrate on introducing most of these methods. If you use reflector, you should see that Interlocked.Read depends directly on the CompareExchange method:

public static long Read(ref long location) {
  return CompareExchange(ref location, 0L, 0L);
}

This is really a cool trick!

As I’ve said before, the CompareExchange method is one of the most important methods exposed by the class. The CompareExchange method receives three parameters: if the first and third parameters are equal, then it updates the first with the value of the second parameter. The method will always return the initial value of the first parameter (even when there’s no update).

So, the code used on the Read method will only end up doing a write (ie, a store) if the current stored value is 0. And even when this happens, there really isn’t any update in the value (notice that if its value is 0 we’re writing 0 again!).

The remaining methods exposed by the class are fairly obvious, so I won’t really go into examples here (the docs do a good job on showing how to use these methods). The important thing to take from this post is that these operations are atomic and are performed at the hardware level. On the next post, we’ll keep talking about this class and on how you can reuse them to add some free lock programming to your apps. Keep tuned!

Multithreading: hardware atomicity

luisabreu — Mon, 29 Jun 2009 21:41:30 GMT

In the previous post, we’ve started looking at memory loads and stores reordering. In this post, we’re going to keep our study and we’re going to introduce atomicity. Atomicity is a really important concept we’ve met in the past. We’ve already talked about it on a higher level: do you recall our discussion on critical regions (and how they’re implemented through critical sections)?

With critical regions we were able to get atomicity at a high level (though at a logical level – recall that using a critical region you can have a “logical” instruction which is really a group of low level instructions). In this post, we’re really into understanding memory loads and stores and that’s why we’re interested in low level atomicity. At this level, atomic operations are performed as a single instruction between the processor and memory and ensure that a thread never sees a corrupt value.

Regarding memory access, all processors ensure that we have atomic loads and stores of aligned word sized values (note that I’m talking about the current processors on which windows can run).

Since I’m also a beginner, I think that explaining these concepts a little bit more might be a good idea. Lets start with the concept of word sized values. Word sized values, aka pointer sized values, represent the maximum amount of memory a processor can handle at a time. for instance, on a 32 bits processor, the word sized value is 32 bits, ie, 4 bytes. On a 64 bit processor, you get an 8 byte word sized value. Notice that we generally use bytes for memory sizes instead of bits. I guess that you’ve got the general idea, right?

Now, the second part, which is also important: aligned. We say that a value is aligned if its address begins at a position which is evenly divisible by a certain memory unit size. For instance, a value is said to be 4 byte aligned if its memory starts on a position which is evenly divisible by 4. Here’s a practical example: if you’re loading a word sized value which “starts” at 0x28, then you can be sure that you’re accessing a value that can be 4 or 8 byte aligned (notice that 0x28 = 40 in decimal, which is evenly divisible by 4 or by 8 ).

Since this is really important, I guess I’ll repeat myself again: you’ll *only* get atomicity when you load or store an aligned word sized value. If you’re loading or storing a value which is smaller than the processor’s word size, you’ll still need to respect the current alignment. For instance, if you’re in a 32 bit processor, where words are 4 bytes long, then that value should be positioned on a position whose address is divisible by 4 (note that you’ll probably need to “fill” – relax, this is generally done by the compiler :) - the other 3 bytes with padding so that the next value is also aligned to ensure proper atomicity).

On the other hand, if you need more space than is available for the current processor’s word size, then you will not get hardware atomicity for that load or store (and this happens even if the value is aligned). In these cases, you’ll need to watch out because you can’t simply load and store a value without any further consideration. If you do this, then you can end up with a thread loading the value before another has completed storing it! (btw, this is know as torn read)

(It’s important to understand that this behavior is also observed for chunks of memory smaller than or equal to the processor’s word size if that value isn’t aligned.)

For instance, this means that if you’re writing multithreaded code that uses long variables and you’re running that code in 32 bits processors, then you shouldn’t forget to protect those write and read operations ! (in future posts. we’ll talk about interlocked operations; if you’re not using them, then you’ll need at least a lock - but don’t get too smart using a lock for “writing only” because that will not work in all the scenarios).

Now that we’re clear on alignments and processor’s word sizes, it’s time to take a quick look at how things work in the CLR. The good new is that the C# compiler and the JIT ensure proper alignment in all cases. In practice, values bigger than 4 bytes on 32 bits processors and values bigger that 8 bytes on 64 bits processors always start on 4 or 8 byte aligned boundaries. When we’re working with smaller values, the CLR will also ensure proper placement, filling the remaining space with padding.

If you want, you can have more control over the way fields are aligned. If you’ve done interop programming, then you’ve surely met the StructLayoutAttribute class. This class allows you to control the way fields are defined on the layout of a specific type. If you’re thinking about using this feature (for instance, to control the amount of wasted memory), then proceed with care (in fact, think thrice – yes, I learned this word a few days ago and i could hardly wait for using it in a post :) - before going down this path!). It’s that you can easily end up loosing the CLR’s type safety and that means you’ll probably end up getting exceptions from your code at runtime.

It’s important to understand that whenever you work with values that fall out of the aligned word size value (a non-aligned value or a value bigger than the current word size), the compiler will end up generating multiple instructions. As we’ve seen, these might end up leading to torn reads if you don’t take the necessary precautions.

Notice that even though stores and loads of aligned word sized values are atomic, they don’t really let us do much. Why? Simply because there are several scenarios where we need to check a value before updating and this means that we end up with a load followed by a store. In these cases and in order to ensure atomicity, we’re back to locks (interesting: have you ever though on how locks are implemented?)…or maybe not! The truth is that we’ve got a couple of interlocked operations which ensure atomicity and that are perfect for these scenarios. we’ll talk about them in the next posts. Don’t you think that things are getting rather interesting! Keep tuned!

Multithreading: load and store reordering

luisabreu — Mon, 29 Jun 2009 09:55:28 GMT

Until now, we’ve been busy talking a look at several interesting topics associated with multithreading programming. As we’ve seen, one of the most problematic areas in multithreaded programs is sharing state across multiple threads. As we’ve seen in several posts along this series, we can use a critical regions for ensuring that shared state is accessed by one thread at a time. In other words, using a critical region ensures that access to shared state is serialized leading to correctness of the program.

One thing that surprises many people is learning that single variables access isn’t always safe. Understanding why leads us to a new concept: memory loads and stores reordering. Even though most of us have grown used to thinking that the program executes precisely in the order we wrote it, that isn’t really guaranteed. Currently, memory operations like loads (ie, accessing a variable) and stores (ie, putting a value into a variable) can be reordered under the optimization “banner”:

the first “optimization” you might get will be performed by the compiler. Compilers might move, eliminate (or even add) memory loads and stores to the program of your app. However, compilers will always preserve sequential behavior (though its reordering can break multithreaded code);
processors might also change the way compiled code gets executed. For instance, modern processors tend to use branch prediction to improve the performance of your program. This is just one of the optimizations that may break your code when run in parallel (ie, after adding multithreading to your app).
caches may give you wrong results too. Most modern processor architectures employ several levels of caches. Some are shared between all processors, while others are processor specific. Caches tend to break the “memory as a big array” vision, leading to effective reorder of loads and stores (at least, this is the perception you get when caching starts breaking your code).

After this small introduction, you should be worried about the code you write because it seems like nothing is safe (if even a simple variable access smaller than the “current” processor word size isn’t safe, then what can we do?). Fortunately, there are some guarantees which we can use to write safe multithreaded programs:

instruction reordering cannot break the sequential evaluation of the code. What this means is that your code should always run safely and correctly if you run it through a single thread (meaning that we only need to worry with reordering when we write multithreaded code);
data dependency will always be respected. As an example, this means that if you have something like x = 10; y = x; then memory access won’t be reordered (ie, you will never get y=x; x = 10) because there is a data dependency between x and y;
finally, all platforms conform to a specific memory model which define the rules that are to be followed for memory loads and stores reordering.

I guess that the main thing you should take from these points is that what is run isn’t always what you’ve written. On the next post, we’ll keep looking at these issues and see how critical regions help with memory reordering issues. Keep tuned!

New toy: bamboo table

luisabreu — Sun, 28 Jun 2009 22:44:31 GMT

So, I’ve just got a new toy: a wacom Bamboo table. This should be fun after getting a nice free app for drawing :) Any thoughts?

It’s official: I’m one year older

luisabreu — Sat, 27 Jun 2009 08:32:11 GMT

And that means that I’m 33 years old…damn…

PT LINQ book: it’s finally available on local bookstores

luisabreu — Fri, 26 Jun 2009 20:54:50 GMT

And here’s the proof:

If you’re interested, you can get more info on the publisher’s site.

Multithreading: the BackgroundWorker class

luisabreu — Thu, 25 Jun 2009 10:27:34 GMT

In the last posts of the series, we’ve been looking at many important features related to GUIs and multithreading. Today, we’re going to wrap up this topic with the BackgroundWorker class. The previous posts are really targeted at library developers.

The truth is that having to implement the EAP pattern to have asynchronous behavior is simply too much work. Interact with the SynchronizationContext object to have asynchronous behavior is really too cumbersome and involves too much boilerplate code.

Wouldn’t it be good if we had a reusable class where we’d simply need to write the code for the asynchronous operation and that would be able to let us know when things are done? The good news is that there’s already a component you can use for that: the BackgroundWorker class.

The BackgroundWorker class can be seen as a helper class which encapsulates all that boilerplate code we’ve seen in previous posts. Here’s the public API of this class:

public class BackgroundWorker : Component {
  public event DoWorkEventHandler DoWork;        
  public event ProgressChangedEventHandler ProgressChanged;        
  public event RunWorkerCompletedEventHandler 
                                      RunWorkerCompleted;
  public BackgroundWorker();    
  public void CancelAsync();    
  public void ReportProgress(int percentProgress);
  public void ReportProgress(
                   int percentProgress, object userState);
  public void RunWorkerAsync();
  public void RunWorkerAsync(object argument);    
  public bool CancellationPending { get; }        
  public bool IsBusy { get; }
  public bool WorkerReportsProgress { get; set; }
  public bool WorkerSupportsCancellation { get; set; }
}

As you can see, this API is really similar to the one we ended up after adding cancellation to the initial EAP implementation. The truth is that you can see this class as a reusable EAP implementation. You’ve got several events used for:

signaling the start of an asynchronous operation;
for reporting progress;
for notifying about the completion of an operation.

Asynchronous operations can be started through one of the two overloads of the RunWorkerAsync method. This method ends up firing the DoWork event on a separated thread. You’re supposed to handle this event and put the code that should be run asynchronously in that method.

Cancellation is also available through the CancelAsync method. If you recall our previous discussion about the EAP pattern, then you know that this class supports only one asynchronous operation at a time (notice that the CancelAsync does not receive any object parameter). It’s also important to notice that you need to allow cancellations by setting the WorkerSupportsCancellation property to true.

Reporting is also available: you can use the ReportProgress method for marshalling report information back to the “main thread”. Anyone that is interested in reporting progress should handle the ProgressChanged event. The same observation we’ve made about cancellations is also valid for progress reporting: you need to enable it by setting the WorkerReportsProgress to true.

As you might expect, all the operations are supported through an internal AsyncOperation instance which is created when you invoke the RunWorkerAsync method. And I guess that’s it. With this post, we’ve ended our quick analysis on GUIs and multithreading. However, there’s still a lot of things to talk about multithreading, so I’ll keep writing about it. Stay tuned for more!

Multithreading: AsyncOperationManager and AsyncOperation helpers

luisabreu — Wed, 24 Jun 2009 11:34:12 GMT

In the last posts, we’ve taken a look at how synchronization contexts help marshal work across threads. Today we’re going to talk about two classes (which we’ve already met in the past when we implemented the EAP) that abstract even further the use of synchronization contexts: I’m talking about the AsyncOperationManager and AsyncOperation classes. Let’s start with the AsyncOperationManager class.

The AsyncOperationManager is a simple helper class with very few lines of code in it, as you can see from the next snippet:

public static class AsyncOperationManager {
  public static AsyncOperation CreateOperation(
                          object userSuppliedState);
  public static SynchronizationContext 
                     SynchronizationContext { get; set; }
}

As you can see, this is a static class with only two members. The SynchronizationContext property lets you access or set the current SynchronizationContext. The biggest advantage it offers when compared with accessing the synchronization context through the SynchronizationContext.Current property (which we’ve used in the previous post) is that you’ll always get a valid context (notice the comment in the previous post’s sample).

The CreateOperation method is the only way you have to create an instance of the AsyncOperation type. Each AsyncOperation instance can only track one asynchronous operation. The AsyncOperation type exposes the following members:

public sealed class AsyncOperation {
  public void OperationCompleted();
  public void Post(SendOrPostCallback d, object arg);
  public void PostOperationCompleted(
     SendOrPostCallback d, object arg);
  public SynchronizationContext 
          SynchronizationContext { get; }
  public object UserSuppliedState { get; }
}

A couple of observations about the previous methods exposed by the AsyncOperation type:

you can access the current synchronization context through the SynchronizationContext property;
the UserSuppliedState property lets you access the optional state parameter that you’ve passed through the userSuppliedState parameter (AsyncOperationManager.CreateOperation method);
you’re supposed to use the Post operation to marshal a notification back to the “main” thread;
you’re supposed to signal the end of the asynchronous operation by calling the PostOperationCompleted method.

As you can see, the AsyncOperation will always perform the operation in asynchronous fashion (ie, it will always invoke the Post method of the internal SynchronizationContext). The main difference between Post and PostOperationCompleted resides in an internal flag that is set by the 2nd method. After this flag is set, all invocations of the Post/PostOperationCompleted methods end up throwing exceptions.

By now, I’m thinking that you’ve got enough information for understanding the use of these types when we saw how to implement the EAP pattern in a previous post, so I’m not going to waste your time repeating what has been said before.

And that’s all. With this post, I guess that there’s only one thing to talk about: the BackgroundWorker class. We’ll leave that topic for the next post. Keep tuned for more.

Eric Lippert on C# “top methods”

luisabreu — Tue, 23 Jun 2009 13:33:44 GMT

Another interesting post by the great Eric Lippert.

Multithreading: windows forms and synchronization contexts

luisabreu — Tue, 23 Jun 2009 11:14:07 GMT

In the previous post, we’ve started looking at synchronization contexts. In this post, we’ll take a close look at the widows forms custom synchronization context. Whenever you run a windows form app, you might end up interacting with the WindowsFormsSynchronizationContext. The constructor of this class is responsible for getting a reference to the GUI thread so that it can then create a control which will be used for marshalling the results back to the UI thread.

With a valid reference to a control and after understanding how work is marshaled back to the GUI thread (which involves posting win32 messages to the UI thread – as we’ve seen in this post), it shouldn’t be a surprise to learn that the Post and Send methods are overridden and that the new implementation relies on the BeginInvoke and Invoke methods of the special “marshal” control. Here’s the current implementation copied from reflector:

public override void Post(
        SendOrPostCallback d, object state) {
  if (this.controlToSendTo != null) {
     this.controlToSendTo.BeginInvoke(
                d, new object[] { state });
  }
}
public override void Send(
          SendOrPostCallback d, object state) {
  Thread destinationThread = this.DestinationThread;
  if ((destinationThread == null) || 
      !destinationThread.IsAlive) {
        throw new InvalidAsynchronousStateException(
                    SR.GetString("ThreadNoLongerValid"));
  }
  if (this.controlToSendTo != null) {
    this.controlToSendTo.Invoke(d, new object[] { state });
  }
}

As you can see, the implementation performs several auxiliary verifications to ensure that everything is still ok before going on with the invocation of the methods.

You might be wondering how things get hooked up, ie, how is the WindowsFormsSyncrhonizationContext set up in the current thread’s ExecutionContext. The answer is rather simple: the base Control class performs that task from its constructor, ensuring that whenever you create any window, you end up with the correct synchronization context.

So, how can we use this information for building multithreaded code for GUIs? The first thing you should do is base your code in synchronization contexts. This ensures that you get the correct behavior and don’t need to worry about GUI threads (notice that this should work in other custom environments that have their own custom synchronization contexts). To show you how you can use this class in code, we’re going to update the code of one of the previous posts so that it uses synchronization contexts instead of relying in a control to marshal work back into the GUI thread:

var number = GetNumberFromSomewhere();
button1.Enabled = false;
//should check for null here!
var syncContext = SynchronizationContext.Current;
ThreadPool.QueueUserWorkItem(state => {
  var ctx = state as SynchronizationContext;
  ctx.OperationStarted();
  var isPrime = false;
  Exception thrownException = null;
  try {
    //algorithm for checking if number is prime
  } 
  catch (Exception ex) {
    thrownException = ex;
  } 
  finally {
    ctx.Send(marshaledState => {
      var result = marshaledState as PrimeVerifierResult;
      button1.Enabled = true;
      if (result.ThrownException != null) {
                throw result.ThrownException;
      }
      if (result.IsPrime) {
        MessageBox.Show("Prime number");
      }
   },
   new PrimeVerifierResult(isPrime, thrownException));
   ctx.OperationCompleted();

 }        
},
syncContext);

A couple of observations on the previous snippet:

you should always check the context obtained from the Current property (though that is not done in this snippet);
updating the button’s state needs to be done from the GUI thread. This is a peace of cake because we’ve already got a reference to the current SynchronizationContext (obtained on the GUI thread and passed to the secondary thread through the state parameter) and the only thing we need to do is call Send or Post;
notice how we signal the beginning and ending of an operation by calling the OperationStarted and OperationCompleted methods. This allows us to notify the synchronous context that an asynchronous operation began so that it can perform any operation it sees fit.

Looking at the previous sample, you might think that it’s not as simple as the first one. And you’re right: if I was writing this code, I’d always go with option 1.

If instead of putting this code on the GUI, I told you that you’d need to write a a class that could be reused across several GUIs, then you can probably start seeing value in the previous code. In fact, if you look at it and pay enough attention, you can start to see that it looks a lot like the code we had when we implemented the EAP pattern: the main difference is that his code relies on a SynchronousContext instance while that old code used the AsyncOperation and AsyncOperationManager classes (btw, I’m talking about the internals here!).

The truth is that these classes are just helpers and in the next post we’ll see how they relate with synchronization contexts. Until then, stay tuned!

Multithreading: Introducing synchronization contexts

luisabreu — Tue, 23 Jun 2009 10:08:22 GMT

In the last post, we’ve seen how to marshal back the results obtained on a secondary thread so that controls are updated on the GUI thread. Today we’re going to start looking at synchronization contexts. Synchronization contexts are abstractions for marshalling between threads. In other words, they abstract those scenarios where you cannot call a method from the current thread and need to make sure that the method is executed on a specific thread (as we’ve seen, GUIs fall in this kind of scenario).

As we’ve seen in the previous example, GUI controls can only be updated from the GUI thread and in that example, we’ve relied on the ISynchronizeInvoke method for running the code on the correct thread. In practice, whenever we’ve got a reference to a control, we can use its Invoke or BeginInvoke method to marshal work back to the current thread. The problem is getting a reference to the control. When we build the form, this is simple because we know the controls that are placed on the form and it is easy to get a reference to any of them.

However, suppose we’re building a general component that needs to be reused on several GUI apps. Now things become harder and we’d need to write boilerplate code for getting a control so that we can marshal work back into the GUI thread. This is where synchronization contexts step in and save the day. Before delving into the specifics of the synchronization contexts used on GUIs, lets take a step back an study the general API introduced by the base SynchronizationContext class:

public class SynchronizationContext {
  public virtual SynchronizationContext CreateCopy();    
  public bool IsWaitNotificationRequired();
  public virtual void OperationCompleted();
  public virtual void OperationStarted();
  public virtual void Post(SendOrPostCallback d, 
                               object state);
  public virtual void Send(SendOrPostCallback d, 
                             object state);    

  public virtual int Wait(IntPtr[] waitHandles, 
                            bool waitAll, 
                            int millisecondsTimeout);

  public static SynchronizationContext Current { get; }
  public static void SetSynchronizationContext(
                     SynchronizationContext syncContext);
}

As you can see, you can get (Current property) or set (by calling the static SetSynchronizationContext) a thread’s synchronization context. Synchronization contexts are always obtained through the “current” ExecutionContext (which you can get through the ExecutionContext property of the thread class). Notice that if you want to interact with synchronization contests, you must be prepared for getting a null reference.

Even though a synchronization context is part of the ExecutionContext, it’s important to keep in mind that queuing an item on the thread pool will never propagate the “current” SynchronizationContext (not even when you use the QueueUserWorkItem method – event though the execution context is propagated, the synchronization context is one of the items that will not be propagated to the new thread).

Post and Send are probably the most important methods exposed by the class. As you can see, both expect a SendOrPostDelegate and an option object parameter for passing some state to that delegate. The difference is that Post performs the operation in asynchronous fashion while Send performs a synchronous callback. The default implementation of these methods is rather simple: Post uses the thread pool while send simply invokes the delegate.

The OperationStarted and OperationCompleted methods let you receive notifications when an operation starts and ends. The default SynchronizationContext doesn’t do anything in these methods, but as we’ll see, they can be used for (for example) tracking running operations.

Finally, we’ve got a Wait method. The CLR uses this method for waiting if you the IsWaitNotificationRequired property is set to true. What this means is that whenever you wait on a thread that has a synchronization context that has this property set to true, your wait calls end up being redirected to this Wait method. Custom synchronization contexts override this method to perform some specific actions whenever a thread needs to wait on a specific action.

And that’s it. After this brief introduction, we’re ready to take a look at the synchronization contexts used by windows forms. But we’ll leave that to the next post. Keep tuned!

Multithreading: the ISynchronizeInvoke interface

luisabreu — Mon, 22 Jun 2009 19:26:37 GMT

In the last post, we’ve see that multithreading is almost a necessity in GUIs. We’ve also seen that there are some gotchas associated with it: a control can only be updated from the GUI thread. In practice, this means that we’ll need to marshal back the results to the main thread when they’re ready.

In .NET, the Windows Forms introduces the ISynchronizeInvoke interface for performing that kind of operation:

public interface ISynchronizeInvoke {
  IAsyncResult BeginInvoke(Delegate method, object[] args);
  object EndInvoke(IAsyncResult result);
  object Invoke(Delegate method, object[] args);
  bool InvokeRequired { get; }
}

The Control class (which is reused by all the existing controls) implements this interface, letting you marshal the results back to the main thread by calling one of the Invoke methods.

As you can see from the interface API, you can block the secondary thread until the GUI is updated (in this case, you use the Invoke method, which is equivalent to calling BeginInvoke followed by EndInvoke), or you can perform that work in asynchronous fashion, by invoking the BeginInvoke method and use one of the available approaches for waiting on the IAsyncResult returned. Besides these methods, the Control class offers two extra helper methods which you can use when you don’t need to pass parameters to the delegate:

public IAsyncResult BeginInvoke(Delegate method);
public object Invoke(Delegate method);

These are just shortcuts to the previous methods and don’t offer any benefits over the interface methods.

The InvokeRequired property is there for checking if marshalling is needed. After all, you don’t want to marshal if you don’t have to, right? Checking if marshalling is needed involves getting the Win32 control’s handle and seeing its window’s thread is the same as the current one.

Internally, the control class performs several interesting steps for executing the update on GUI through the Invoke methods(sync or async):

it starts by getting a reference to the control (or parent control) which has an associated Win32 handle;
it checks the associated thread ID (the unmanaged thread ID) and sees if marshaling will be needed (this happens whenever the control’s windows thread is different from the current thread that is calling the Invoke method – this relies in using the GetWindowThreadProcessId win 32 function;
it propagates the current ExecutionContext (more on this in future posts) so that it flows across threads;
if needed, it posts a message by using the Win32 PostMessage method (that’s why it needs to get a reference to a control that has a Win32 handle) and sets up a callback that will be fired when the message is processed.

As you’d expect, there’s a custom IAsyncResult implementation which performs many of the things we’ve seen before (like allocating a lazy event so that it is created only if it’s needed, etc, etc). To show you how easy it is to use marshalling, we’re going to create a Windows Forms test project which will use a secondary thread for calculating if a number is prime. We’ll start with a really simple form which has only one button for starting the operation:

Here’s the code we’ve added to the buttons click event:

private void button1_Click(object sender, EventArgs e) {
  button1.Enabled = false;
  ThreadPool.UnsafeQueueUserWorkItem(state =>
  {
    var isPrime = CheckIfNumberIsPrime((Int32)state);
    Action updater = () => { 
                 MessageBox.Show(isPrime.ToString());
                 button1.Enabled = true;   };
    button1.Invoke(updater, null);
  },
  19// hardcoded number
  );
}

As you can see, we’re making sure that all UI code runs on the GUI thread. The important thing here is making sure that the Enable property is set from the correct thread. In pre-NET 2.0, you could go ahead and set a property from a secondary thread. Most of the time, things would work and you’d get occasional crashes which were difficult to debug. From .NET 2.0 onward, the behavior changed: when you’re running in a debugger, you’ll always get additional checks which verify if the code is being called from the correct thread.

As a final optimization, you’ll probably want to stop the ExecutionContext from flowing in most GUI apps (specially for full trust apps). Doing this is as simple as calling the SuppressFlow method:

ExecutionContext.SuppressFlow();

And that’s it for today. Keep tuned for more on multithreading.

Multithreading: why multithreading on GUIs

luisabreu — Sun, 21 Jun 2009 12:52:17 GMT

In the latest posts, we’ve seen how to implement the event based asynchronous (EAP). When we introduced at the main features of the EAP, I’ve said that you should use this pattern when the consumers of your classes are GUIs programmers.

Since we’ve already learned lots of things about EAP, now it’s probably a good time for starting to look at asynchronous programming and GUIs. GUIs are probably one of the areas which will get the most from multithreading. To understand why, we need to make a small detour on how GUIs work in windows. Since I’m focusing on managed code, from now on I’ll be using windows forms platform for illustrating purposes (notice that the main concepts are common to unmanaged and managed code and it looks like things will remain the same for several years),

On windows, GUIs apps rely on messages for signaling several kinds of operations. What this means is that mouse, keys events, etc end up generating a message that are send to the GUI thread’s message queue. The main job of this thread is to pump the messages that are queued on the message queue.

In unmanaged code, pumping a message generally involves writing a loop that gets a message from the queue (GetMessage) and dispatches it (DispatchMessage) to a a special windows function (notice there’s always a windows function associated to a window – if you don’t create a custom one, you’ll end up with the default one). Windows functions will inspect the message and run some code in response to specific messages.

Back to the managed world and windows forms, you’ll notice that all these details are hidden by several classes. For instance, pumping messages is supported through the Application.Run call which you get by default on all the Windows Forms projects. Notice that this method “transforms” the thread on which it’s called into a GUI thread.

Windows Forms also encapsulates the so called Windows function. In fact, if you look at the Control class, you’ll see that it exposes a protected WndProc method. Internally, this method translates the windows messages into events which you might (or not) handle from your app. Notice that even though there’s plenty of stuff exposed as events, you can still overload this method if you need to handle a windows message directly.

As you can see, we can say that the final result of pumping a message is running some code that performs a specific action. In Windows Forms apps, this generally means handling an event. Now, after the previous paragraph, it should be obvious why you shouldn’t do much work from within your event handlers: if you do a lengthily operation from the GUI thread, you’re not letting it pump more messages, leading to a blocked window (something which we’ve all seen in the past - and probably cursed the guys that have written that app for it:)).

Blocking the GUI thread isn’t such a good idea either. However, it’s important to recall that in windows you can block a thread while pumping messages from the message queue. The CLR does this automatically for you and you have no control over it (which is good and bad as we’ve seen in the past).

Now, since you already know lot of things about multithreading, you know that you can easily execute that lengthily operation on a separated thread. The problem is that all windows controls have thread affinity and can only be updated from the GUI thread. This means that when we are on a secondary thread, we need to marshal the results back to the GUI thread if we need to change a property of a control.

As you can see, using separate threads on GUI programming is a must for ensuring proper response from our application. However, it also needs special care for guaranteeing that everything works as expected. In the next posts we’ll start looking at some practical examples which show how to use multithreading on GUIs and on the internal details that support this kind of operations. Keep tuned!

Multithreading: updating the code to support multiple asynchronous executions of one method

luisabreu — Sat, 20 Jun 2009 14:26:42 GMT

In the previous posts, we’ve seen how to implement the asynchronous event based pattern and how to support several features:

executing the task asynchronously;
support progress notification;
support cancellation.

Today we’re going to update our initial code to support several simultaneous asynchronous calls of the same method. If you look at that code, you’ll notice that for supporting a single operation, we’re using several fields:

an AsyncOperation (_currentOperation) instance that represents the current operation;
a boolean field (_isRunning) which indicates if there’s currently a running operation;
a boolean field used for supporting cancellation.

Going multi-method is not really complicated, though it means we need to pay more attention to the way the internal fields of the class are accessed. The first thing we’ll need is a container for storing several items. You probably recall from previous posts that we mentioned an optional Object parameter for several of the methods exposed by a class. This optional parameter stops being optional when we want to support several asynchronous operations. In practice, it’s used as a key that identifies a specific asynchronous execution. Notice that the consumer of the API must remember that key if it wants to get progress info or if it needs to cancel a running operation. In this case, we’ll be using a Dictionary<Object, AsyncOperation> as the container that stores all the running asynchronous operations.

Using a dictionary means that will have to translate the operations that relied on the fields into methods that use the dictionary. Here are the methods we’ve ended up adding to the previous class:

private IDictionary<Object, AsyncOperation> _operations = 
                  new Dictionary<Object, AsyncOperation>();
private void AddOperation(Object key, AsyncOperation operation) {
  lock (_operations) {
    if (_operations.ContainsKey(key)) {
      throw new ArgumentException();
    }
    _operations.Add(key, operation);
  }
}
private AsyncOperation GetOperation(Object key) {
  AsyncOperation operation = null;
  lock (_operations) {
    operation = _operations[key];
  }
  return operation;
}
private void CancelOperation(Object key) {
  lock (_operations) {
    _operations[key] = null;
  }
}
private void EndOperation(Object key) {
  lock (_operations) {
    _operations.Remove(key);
  }
}
private Boolean IsRunning(Object key) {
  var isRunning = false;
  lock (_operations) {
    isRunning = _operations.ContainsKey(key) && 
                _operations[key] != null;
  }
  return isRunning;
}
private Boolean OperationWasCancelled(Object key) {
  Boolean cancelled = false;
  lock (_operations) {
    cancelled = _operations.ContainsKey(key) && 
                _operations[key] == null;
  }
  return cancelled;
}

As you can see, we’ve added several methods that lets cancel an operation (CancelOperation), check if an operation is running (IsRunning), check if an operation was cancelled (OperationWasCancelled) and clear an operation which has ended from the private dictionary (EndOperation). Notice that we’re using locks for ensuring proper dictionary access.

There are a couple of interesting changes between the previous snippet and the old code:

the first thing you should notice is that the asynchronous operations can only be identified by a key (we’ll see from where that key comes in the next paragraphs) and that’s why all the helper methods receive one.
if you compare the “running” concept implementation with the one we have in the previous snippet, you should notice that running means having a valid entry with the specified key (in the previous simpler code, we used a simple field for checking if a task was running);
cancelling means that we set the associated AsynchronousOperation to null but don’t remove the entry from the dictionary;
we’ve also got a helper method that should only be called when the asynchronous operation ends and is responsible for removing everything from the entry from the dictionary.

The next thing we need to change is the IsPrimeAsync method. Besides adding the Object parameter used for identifying an asynchronous operation, we also need to change the internal code used by that method:

public void IsPrimeAsync(Int32 number, Object key) {
  if (IsRunning(key)) {
      throw new InvalidOperationException();
  }
  var currentOperation = AsyncOperationManager.CreateOperation(null);
  AddOperation(key, currentOperation);
  ThreadPool.QueueUserWorkItem(state =>  {
    var numberToCheck = (Int32)number;
    var isPrime = false;
    Exception throwException = null;
    try {
      if (number > 2) {
        isPrime = true;
        var half = number / 2;
        var currentProgress = 0f;
        for (var i = 2; i < half && 
                  !OperationWasCancelled(key); i++) {
            if (number % i == 0) {
                isPrime = false;
                break;
            }
            currentProgress = ((float)i  / (float)half) * 100;
            currentOperation.Post(
              evtState => OnProgressChanged(
                  (ProgressChangedEventArgs)evtState),
                  new ProgressChangedEventArgs(
                    (Int32)currentProgress, key));
          }                                
      }
    } 
    catch (Exception ex) {
        throwException = ex;
    } 
    finally {
        NotifyEndOfOperation(
          numberToCheck, 
          isPrime, 
          OperationWasCancelled(key), 
          throwException, 
          key, 
          currentOperation);
    }
  }, number);
}

I think there’s not much to say about this method: the principles are the same as before but now everything is encapsulated by several helper methods. As you can see, we’ve updated the code use for propagating progress (now we pass the key that identifies the operation, instead of passing null) and we’ve also changed the API of the NotifyEndOfOperation so that it also receives the associated AsyncOperation instance and its key (we could always get the key from the UserSuppliedState property of the AsyncOperation instance, but I preferred to be explicit about it). Here’s the code for that method:

private void NotifyEndOfOperation( Int32 numberToTest,
  Boolean isPrime,
  Boolean cancelled, 
  Exception thrownException,
  Object key,
  AsyncOperation currentOperation ){
    var evt = new PrimeNumberVerificationCompletedEventArgs(
            numberToTest, isPrime, thrownException, cancelled, key);
    currentOperation.PostOperationCompleted(
          evtState => {
            EndOperation(key);
            OnPrimeNumberCompleted(
              (PrimeNumberVerificationCompletedEventArgs)evtState);
         }, 
        evt);
}

The main point of interest here is that we’ve updated the instantiation of the PrimeNumberVerificationCompletedEventArgs so that if is able to flow the key that identifies the operation that ended. Notice also that we clear the current AsyncOperation from the dictionary before notifying the user of the completion of the task.

The only thing needed is updating the code used for cancelling a running task:

public void CancelAsync(Object key) {
  if (OperationWasCancelled(key)) {
      return;
  }
  CancelOperation(key);
}

And that’s it. With this post, I’d say that there really isn’t much more to say about this pattern. Keep tuned for more on multithreading apps!

Multithreading: reporting progress on the asynchronous task

luisabreu — Sat, 20 Jun 2009 12:06:54 GMT

I know that I’ve said that the next post of the series would be on how to support several asynchronous tasks. However, I was reminded by a friend that I didn’t had any post on how to support the optional progress info feature. So, I decided to take a small detour today and we’ll see how we can modify our class so that it is able to report progress back to the user.

As we’ve seen, progress is exposed through an event named ProgressChanged, of type ProgressChangedEventHandler (notice that if you have several diferent asynchronous method, then you should name the event XXXProgressChanged, where XXX is the name of the asynchronous method).

Here’s the code we’re using to fire the event:

public event ProgressChangedEventHandler ProgressChanged;
protected void OnProgressChanged(ProgressChangedEventArgs evt){
    if (ProgressChanged != null) {
        ProgressChanged(this, evt);
    }
}

As you can see, this is standard stuff, ie, we’ve added the event and then an OnEventName method which is responsible for firing the event (btw, keep in mind that if the class you’re building isn’t sealed, then you should make the method virtual so that a derived class can use overrides as a way to “handle” the event ).

As you might guess by now, progress report must come from the method that does the work. In this case, we’re talking about an anonymous method that is passed to the ThreadPool.QueueUserWorkItem method. In this example, calculating the progress is easy and depends on the total number of elements used in the for loop:

public void IsPrimeAsync(Int32 number) {
  if (_isRunning) {
      throw new InvalidOperationException();
  }
  _isRunning = true;
  _currentOperation = AsyncOperationManager.CreateOperation(null);
  ThreadPool.QueueUserWorkItem(state =>  {
      var numberToCheck = (Int32)number;
      var isPrime = false;
      Exception throwException = null;
      try {
        if (number > 2) {
          isPrime = true;
          var half = number / 2;
          var currentProgress = 0f;
          for (var i = 2; i < half && !_cancelOperation; i++) {
              if (number % i == 0) {
                  isPrime = false;
                  break;
              }
              currentProgress = ((float)i  / (float)half) * 100;
              _currentOperation.Post(
                      evtState => OnProgressChanged(
                             (ProgressChangedEventArgs)evtState ),
                      new ProgressChangedEventArgs(
                           (Int32)currentProgress, null));
            }                                
        }
      } 
      catch (Exception ex) {
          throwException = ex;
      } 
      finally {
          NotifyEndOfOperation(numberToCheck, 
              isPrime, _cancelOperation, throwException);
      }

    }, number);
}

If you compare this code with the previous snippet, you’ll see that we added a currentProgress local variable for tracking the progress of the current operation and that we’re using our AsyncOperation instance (_currentOperation field) for marshalling the results and invoking the OnProgressChanged event from the “main thread” (where “main thread” is the thread that started the operation). And that’s it. From this point on, you can also get progress information by hooking up the ProgressChanged event:

work.ProgressChanged += (sender, e) => { //do something here with progress info};

And that’s it for today. On the next post, we’ll talk about the changes we need to make to the current code so that we can support several asynchronous executions of the IsPrimeAsync method. Keep tuned!

PS: I’ve followed Tuna’s twitter suggestion and I’ve used a plug-in for showing code in color. Do you guys prefer it this way?

Multithreading: adding cancelation to the initial event based pattern implementation

luisabreu — Thu, 18 Jun 2009 21:45:36 GMT

Today we’re going to improve the code we’ve started writing yesterday: we’re adding canceling support. As you might recall, in our last post we’ve built a simple class which supports a single asynchronous operation at a time. Since we only support one asynchronous operation at a time and we can only start one asynchronous operation from our class, then we only need to add a parameterless CancelAsync method.

Here’s how you might implement the CancelAsync method:

public void CancelAsync() {
    if (!_isRunning) {
       return;
    }
    _cancelOperation = true;
}

As you can see, we need to add a _cancel operation field which is used for notifying the helper method that runs in asynchronous mode that it should stop. This means that we need to change our asynchronous method slightly so that it checks that value in the for cycle and passes that value for the PrimeNumberVerificationCompletedEventArgs instance passed to whoever consumes the PrimeNumberCompleted event. Since I’ve cheated a little bit in the previous post, we’ve already got the hooking points for flowing the needed information. This means that changes are mostly concentrated on the IsPrimeAsync method:

public void IsPrimeAsync(Int32 number) {
if (_isRunning) {
      throw new InvalidOperationException();
}
_isRunning = true;
_currentOperation = AsyncOperationManager.CreateOperation(null);
ThreadPool.QueueUserWorkItem(state =>
                  {
                      var numberToCheck = (Int32)number;
                      var isPrime = false;
                      Exception throwException = null;
                      try {
                          if (number > 2) {
                              isPrime = true;
                              var half = number / 2;
                              for (var i = 2; i < half && !_cancelOperation; i++) {
                                  if (number % i == 0) {
                                      isPrime = false;
                                      break;
                                  }
                              }
                          }
                      }
                      catch (Exception ex) {
                          throwException = ex;
                      }
                      finally {
                          NotifyEndOfOperation(numberToCheck,
                                               isPrime,
                                               _cancelOperation,
                                               throwException);
                      }

}, number);
}

There’s still one thing missing: we need to clean up the _cancelOperation flag when that asynchronous operation ends. This can be done from within the anonymous method we’re using inside the NotifyEndOfOperation method:

private void NotifyEndOfOperation( Int32 numberToTest,
Boolean isPrime,
Boolean cancelled,
Exception thrownException ){
      var evt = new PrimeNumberVerificationCompletedEventArgs(
                  numberToTest,
                  isPrime,
                  thrownException,
                  cancelled,
                  null);
      _currentOperation.PostOperationCompleted(
          state => {
                      _isRunning = false;
                      _cancelOperation = false;
                      OnPrimeNumberCompleted((PrimeNumberVerificationCompletedEventArgs)state);
                   },
                  evt);
}

And that’s it. As you can see, supporting cancelation is not really that hard. We’ll keep improving this sample and on the next post we’ll see how we can improve our code so that it supports multiple asynchronous operations. Keep tuned.