June 2009 - Posts

Multithreading: hardware atomicity
Mon, Jun 29 2009 22:41

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
Mon, Jun 29 2009 10:55

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
Sun, Jun 28 2009 23:44

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?

by luisabreu | 6 comment(s)
Filed under:
It’s official: I’m one year older
Sat, Jun 27 2009 9:32

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

by luisabreu | 4 comment(s)
Filed under:
PT LINQ book: it’s finally available on local bookstores
Fri, Jun 26 2009 21:54

And here’s the proof:

IMAG0281

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

by luisabreu | 2 comment(s)
Filed under:
Multithreading: the BackgroundWorker class
Thu, Jun 25 2009 11:27

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
Wed, Jun 24 2009 12:34

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”
Tue, Jun 23 2009 14:33

Another interesting post by the great Eric Lippert.

by luisabreu | with no comments
Filed under:
Multithreading: windows forms and synchronization contexts
Tue, Jun 23 2009 12:14

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
Tue, Jun 23 2009 11:08

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
Mon, Jun 22 2009 20:26

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:

frm

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
Sun, Jun 21 2009 13:52

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!

by luisabreu | with no comments
Filed under: ,
Multithreading: updating the code to support multiple asynchronous executions of one method
Sat, Jun 20 2009 15:26

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

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!

by luisabreu | with no comments
Filed under: ,
Multithreading: reporting progress on the asynchronous task
Sat, Jun 20 2009 13:06

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?

by luisabreu | with no comments
Filed under: ,
Multithreading: adding cancelation to the initial event based pattern implementation
Thu, Jun 18 2009 22:45

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.

Multithreading: implementing the event based pattern
Wed, Jun 17 2009 22:38

In the last post of the series, we’ve taken a look at the main features offered by the event based pattern. Today, we’re going to look at how we can implement that pattern. We’re going to start small and we’re going to reuse the IAsyncResult sample for showing how you can implement this pattern.

As we’ve seen in the previous post, we need to (at least) add a method (named XXXAsync) that will start the asynchronous operation and an event (named XXXCompleted) that will fire . In practice, this means that we need something like this:

class DoSomeWork {
    public Boolean IsPrimeNumber(Int32 number) {
        /* same as before*/
    }
    public event EventHandler<PrimeNumberVerificationCompletedEventArgs> PrimeNumberCompleted;
    protected void OnPrimeNumberCompleted( PrimeNumberVerificationCompletedEventArgs evtArgs ){
        if (PrimeNumberCompleted != null) {
            PrimeNumberCompleted(this, evtArgs);
        }
    }
    public void IsPrimeAsync(Int32 number) {
     //some code here…
    }
}

As you can see, we’ve got a PrimeNumberVerificationCompletedEventArgs that is passed back. As we’ve said, this must be a AsyncCompletedEventArgs (or derived) class. In this case, we need to return a value, so we’ll need to create a new derived class which I called PrimeNumberVerificationCompletedEventArgs. Here’s the code for that class:

public class PrimeNumberVerificationCompletedEventArgs: AsyncCompletedEventArgs {
    private readonly Int32 _testedNumber;
    private readonly Boolean _isPrime;
    internal PrimeNumberVerificationCompletedEventArgs( Int32 testedNumber,
        Boolean isPrime,
        Exception exception,
        Boolean calculationCanceled,
        Object state )
        : base(exception, calculationCanceled, state) {
        _testedNumber = testedNumber;
        _isPrime = isPrime;
    }
    public Int32 TestedNumber {
        get{
            RaiseExceptionIfNecessary();
            return _testedNumber;
        }
    }
    public Boolean IsPrime{
        get{
            RaiseExceptionIfNecessary();
            return _isPrime;
        }
    }
}

As you can see, I’ve added two properties to the base class: TestedNumber (returns the number that was passed to the IsPrimeAsync method) and IsPrime (returns the result of the processing). As you can see, both properties call the RaiseExceptionIfNecessary method before returning the value back to the client. Internally, this method will throw the exception (when it isn’t null) that supposedly originated during the asynchronous operation and that was passed to the constructor.

As you might expect, most of the action happens on the IsPrimeAsync method. From within that method, we need to start the processing on a different thread. For starters, we’re allowing only one asynchronous call at the time. Here’s a possible implementation for 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; i++) {
                                    if (number % i == 0) {
                                        isPrime = false;
                                        break;
                                    }
                                }                               
                            }
                        }
                        catch (Exception ex) {
                            throwException = ex;
                        }
                        finally {
                            NotifyEndOfOperation(numberToCheck, isPrime, false, throwException);
                        }

                    }, number);
}

There are a couple of interesting points here:

  • we start by creating an AsyncOperation instance (_currentOperation is a field of the class) by using the helper AsyncOperationManager class. As you’ll see, this class handles most of the work for us and I’ll have much more to say about it in future posts (I guess that when I finish this topic, I’ll go straight into GUI and multithreading);
  • we use an auxiliary field (_isRunning) which is signaled when we start a new operation. Since this first version does not support more than one asynchronous call at a time, we end up throwing an exception whenever the method is called before it ends the “current” running asynchronous operation;
  • we need to wrap our code in a try/catch block so that we catch all the exceptions that might happen during the execution of that code (this is not without its problems – what to do with an out of memory exception? – but it ensures that a less “critical” exception doesn’t crash the process). Notice that eventual exceptions are saved on local field so that they can be passed to the client of the event.

The NotifyEndOfOperation method is responsible for “firing“ the event back on the thread that started the request (which is really needed when you’re writing code for GUIs). To do that, it must first pack all the info into a PrimeNumberVerificationEventsArg expected by the consumer of the API. As you’ll see, the method ends up being really simple because we end up relying once again on the “mysterious” AsyncOperation class:

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;
              OnPrimeNumberCompleted((PrimeNumberVerificationCompletedEventArgs)state);
           },
           evt);
}

As I’ve said before, we’ll spend a couple of posts on GUIs and asynchronous processing. Until then, just know that calling this method signals the end of an asynchronous operation (notice also that this means that you cannot make future calls over this AsyncOperation instance). From within the delegate we pass to the method, we turn off our running flag and fire the event by calling the auxiliary OnPrimeNumberCompleted method:

protected void OnPrimeNumberCompleted( PrimeNumberVerificationCompletedEventArgs evtArgs ){
    if (PrimeNumberCompleted != null) {
        PrimeNumberCompleted(this, evtArgs);
    }
}

And now that we’ve got the class ready, here’s how you’re expected to use it:

var work = new DoSomeWork();
work.PrimeNumberCompleted += (sender, e ) => {
                                 Console.WriteLine(e.IsPrime); evt.Set();
                             };
work.IsPrimeAsync(19);

There still more to say about this pattern, so we’ll return to it in future posts. Keep tuned!

More on the III Exposition of Vintage and Classic cars
Tue, Jun 16 2009 20:06

I’ve uploaded some more pics to the Facebook album. These were taken with the camera, so they don’t have the same quality as the previous ones.

by luisabreu | with no comments
Filed under:
Book review: Here comes everybody
Tue, Jun 16 2009 17:08

In my latest mini-vacations, I had some free time to update my reading stack. One of the books I read was Clay Shirky’s Here Comes Everybody. After seeing it well referenced in Jeff Atwood’s blog, I’ve bought and saved it for future reading.

In this book, Clay Shirky talks about the new opportunities available for group organization with the introduction of new technologies and social tools. It’s a really well written book (I managed to read it in 2 days while getting a tan by the pool :)) which presents several interesting stories that will keep you hooked until the last page.

Overall, I’m giving it a 9/10 for its content and writing quality.

by luisabreu | with no comments
Filed under:
C#4.0: clearing up some doubts
Tue, Jun 16 2009 16:53

After my last post on C# 4.0, I’ve had an interesting exchange of tweets with Thomas Johansen about the usefulness of the code I’ve shown. As Thomas points out, knowing the type means that you should always cast it to that type so that you work with strongly typed verification (ie, compile time checking). In practice, what he’s saying is that example is completely useless because if you know the type of the object you’re creating, then you should always cast it to that type before using it.

I do  agree with him and that’s why I’ve ended up writing this post so that there isn’t any doubt regarding what you should do: whenever possible, you should work with the type instead of relying in dynamic types or in reflection.

Since I’ve already published the code, what I’d really like is that you concentrate only in the dynamic usage parte and read the CreateInstance invocatio as GetMeADynamicObjectFromSomewhereWhichHasSeveralKnownProperties. Can you guys do that? thanks :)

by luisabreu | with no comments
Filed under:
Multithreading: introducing the event based asynchronous pattern
Tue, Jun 16 2009 10:06

In the last posts we’ve looked at several details associated with the use of the APM pattern. Today we’re going to start looking at the second pattern for doing asynchronous work: the event based asynchronous pattern.

This pattern was introduced with .NET 2.0 and it targets components that are going to be used in GUIs. In other words, if you’re building components that are going to be used by developers that build GUIs, then you should prefer this pattern instead of the APM.

To implement this pattern, a class needs to:

  • have a method with the name XXXAsync, where XXX is the name of the synchronous method;
  • the XXXAsync method receives the same parameters that are expected by the synchronous version plus an optional object parameter (used to pass extra state that should be consumed later);
  • expose an event with the name XXXCompleted, which should be fired when the asynchronous task completes;
  • the EventArgs type of that event should be an AsyncCompletedEventArgs derived class;
  • expose a CancelAsync method (which might optionally receive an object parameter) that is responsible for cancelling the async operation;
  • optionally expose a ProgressChanged event (of type ProgressChangedEventHandler), that can be consumed for getting info  on the progress of the operation.

Unlike the APM, the XXXAsync method that starts the asynchronous task does not return an IAsyncResult instance (in fact, it always returns nothing, ie, void). This means that the only option available for “waiting” for the completion of the task is handling the event.

Notice that a class that has one XXXAsync method might support the execution of several concurrent tasks. In those cases, you do need to have the extra state parameter I’ve mentioned above because it is used for distinguishing between the multiple executing operations (if you don’t want to support multiple execution, then you don’t need that extra parameter).

If you’re building GUIs (ex.: windows forms apps), you don’t really care much about the flexibility of the APM. In fact, in these scenarios, the event based pattern is your best option. Why? Simple: because the method that handles the event will be fired on the GUI thread (which, btw, is required for interacting with the controls – ie, whenever you need to update a control, you need to do it from the GUI thread).

Another great feature of the event based pattern is that it offers first class cancelation support (which does not happen with the APM). As we’ve seen, a class that implements this pattern needs to expose a CancelAsync method, which the consuming developer can use for cancelling the current asynchronous operation. Notice that when you support multiple concurrent executions, you need to pass the state parameter to this method so that the class knows which operation should be cancelled.

Reporting on progress is another great feature which is very important for GUIs (generally, giving feedback about the status of the current operation is important for this kind of apps). As we’ve seen, a component that implements this pattern might decide to support this feature by exposing a ProgressChanged event. Notice that if the class exposes several XXXAsync method, then you should expose several events named XXXProgressChanged.

And I guess this sums it up. More about this pattern and multithreading on the next posts. Keep tuned.

More Posts Next page »