Yet Another C# Blog

I’ve spent the last 4 posts talking about Regular Expressions and some difficult patterns. But, this is a C# blog, so I really want to be talking about C#. Today, I hope to provide you with a nice little start on a multi-threading "Task Queue" application. A Task Queue will place task requests in a queue that will be serviced Asynchronously and in the order received. Rather than keep you in suspense, here’s the code up front. If you'd like an explanation, I've attempted that below. (Update 10/6/2008: Sorry folks about the bug below. The Enqueue method must set the the Busy field to true when queing the first task in order to avoid the thread race. It's now been fixed.) using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.Threading; namespace TaskQueuePOC { public partial class Form1 : Form { public...

Suppose you've been given the task to write a function that copies the contents of one folder to another. So you set off on your merry way and come up with something like the following. using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.IO; namespace ThreadPoolPart4 { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e) { // Get the Folder names, copy contents from one to the other FolderBrowserDialog fb = new FolderBrowserDialog(); fb.ShowDialog(); string src = fb.SelectedPath; fb.ShowDialog(); string dst = fb.SelectedPath; // no error checking on the names, this is an example only if (dst != src)...

To wrap up this series of articles, I am going to make the application we've been working on do something a little more interesting. If you will recall in my first article on the subject of ThreadPool , I go over several ways to call the primary thread pool function QueueUserWorkItem and demonstrate how simple it is to multi-thread an application. In my second article, I look at a skeletal application that doesn't really do anything; it just displays messages on the console. However, and more importantly, it demonstrates some of the aspects of synchronization. You must synchronize if you are to do anything of real consequence with threads. So, what sort of interesting things will this application do? My application will paint a pop-art picture. Actually, it will place random pixels on a PictureBox. Okay, its not that useful (or argueably that interesting), but it will demonstrate a means by which threads report progress to the GUI thread. Let's look at the work it...

Let's continue looking at System.Threading.ThreadPool . In the last article , we went over some of the basic features a thread pool should have. We looked specifically at System.Threading.ThreadPool to see how to get your App threading quickly. And, we touched on some aspects missing from Microsoft's thread pool implementation that are needed for an "industrial strength" application. So today, we will examine some of those missing features. Let's start with a skeleton application. This application starts a master work item that is responsible for feeding service work items to the thread pool. The service work items do some work (right now, they display a message with Console.WriteLine(...) and then sleep a random amount of time in the sub-second range). We get a taste of synchronization with the shared random number generator where I surround it with a lock(...){ } statement to make it thread safe. When service work items are done, they exit. "Ex...

The System.Threading.ThreadPool is a great little feature for programmers wishing to add instant threading to their applications. You just enqueue callback functions, what could be more simple than that? I agree, so we'll look now at some simple coding experiments with the ThreadPool . By the way, here's the MSDN version of "How to: Use a Thread Pool" which makes for some good pre-requisit reading. And though I risk repeating much of what may be already elsewhere on the web, I hope that I can add something of use in your estimation. So first, let's get a basic understanding of thread pooling. Maybe you've already read my article, Thread Synchronized Queing . If so, you have a good start. A thread pool, like my SynchQueue class, will involve some thread(s) writing to a queue, and some set number of threads reading from the queue. Similarly, if there isn't enough work to do, the reader threads wait or block on the queue. And, if there is too much ...

Sometimes mundane things turn out to be really nice after all. No, I'm not talking about one of your last dates. I'm talking about timers, yes, the Timer classes in C#. These little tools are found everywhere in programming, and it seemed for the longest time, there was only one stock timer to choose from. Well, now there are three. Before I go any further, let me recommend to you Alex Calvo's MSDN magazine article Timers: Comparing the Timer Classes in the .NET Framework Class Library . Here, you will find some good background for applying timers to your application. But, in this little series, I want to look at how the timers interact with the event loop. This first article in the series will look at the System.Windows.Form.Timer. The System.Windows.Form.Timer is supposed to be synchronous with respect to the rest of your Windows Forms app. That means, if you "sleep" or block in some other way, the timer will stop working (while sleeping). However, progr...