Posted on 1/27/2010 9:40:52 AM by Justin Etheredge
Inside of .NET 4.0 there are numerous new namespaces, but the one that we are here to talk about today is called System.Collections.Concurrent. This namespace contains a handful of types which implement different types of thread-safe collections. The thread-safe collection type that we are going to take a look at today is the ConcurrentBag<T>.
The ConcurrentBag<T> is one of the most simple concurrent types which has been introduced. It is a typical bag data structure (also known as a multiset), meaning that it is an unordered collection of items that allows duplicates. It is called a bag because if you were to draw a diagram of the data structure, it would look something like this:
Just a jumble of items, with no order at all. It has three important methods, which are "Add", "TryTake", and "TryPeek". Add works exactly as you would expect, you simply instantiate a ConcurrentBag instance and then call Add in order to put items into it:
Continue reading the rest of this post...
Posted on 1/25/2010 4:05:10 PM by Justin Etheredge
In the soon-to-be-released .NET 4.0 framework and Visual Studio 2010 we are going to get a plethora of new tools to help us write better multi-threaded applications. One of these tools is a new namespace within the System.Threading namespace which is called "Tasks". The Tasks in System.Threading.Tasks namespace are a method of fine grained parallelism, similar to creating and using threads, but they have a few key differences.
The main difference is that Tasks in .NET 4.0 don't actually correlate to a new thread, they are executed on the new thread pool that is being shipped in .NET 4.0. So, creating a new task is similar to what we did in .NET 2.0 when we said:
ThreadPool.QueueUserWorkItem(_ => DoSomeWork());
Okay, so if all we are doing is just plopping a new task on the thread pool, then why do we need this new Task namespace? Well, I'm glad you asked! In previous versions of .NET, when we put an item on the thread pool, we had a very hard time getting any information back about what exactly was going on with the piece of work that we had just queued. For example, in the code above, what would we have had to do in order to wait on that piece of work to finish? The thread pool doesn't give us any built-in way to do this, it is just fire and forget.
Continue reading the rest of this post...
Posted on 1/22/2010 2:57:13 PM by Justin Etheredge
I can't believe I'm involving myself in this conversation. In fact, as I write this I am dying a little bit on the inside. Both Nate and Rob are probably going to shake their heads in disgust at me, but I've come across two blog posts today that have made my skin crawl a bit, and so I feel I have to dip my toe into this water. And so here it goes....
CONTROLS DO NOT MAKE YOU MORE PRODUCTIVE.
I seriously thought about putting some nice "marquee" tags around that, maybe a little blinking would help drive the point home.
But there, I said it. You people need to get over your control obsession. Whenever I see people comparing MVC and Web Forms, it is always "MVC is less productive because it doesn't have controls." People will acknowledge that MVC has "helpers", but helpers apparently don't fill the same role as controls. Oh, the argument is that MVC gives you more control, but since I can't drag and drop a bunch of stuff on a form, then it makes me sooooooo slow. <insert your own picture of Eeyore here>
Continue reading the rest of this post...
Posted on 1/21/2010 1:10:02 PM by Justin Etheredge
How many of you have created new year's resolutions in the past? Come on, be honest with yourself, you know that you have thought about creating a new year's resolution at least once or twice. And how many times have you succeeded with those new year's resolutions? If you're anything like me, you have long ago given up on new year's resolutions because they are something that you impress upon yourself in the wee hours of January first after having imbibed one too many glasses of champagne.
You see, resolutions don't really work because people just don't take them that seriously, and they are something that we do on a whim. If we actually wanted to change, then we wouldn't wait for January 1st in order to make the decision. Or maybe we don't want to change? Maybe the problem we have isn't really causing us that much pain? But is that really the case?
Continue reading the rest of this post...
Posted on 1/20/2010 9:30:21 AM by Justin Etheredge
How many MIT graduates does it take to copy a file?
Continue reading the rest of this post...