Archive for February 2010
Yet another “Code to Look At”
In the last post I mentioned some code samples from Interesting Finds by Jason Haley. Specifically, the Code to Look At section of the blog.
Here is yet another example of an interesting piece of code I found in that section: The .NET Asynchronous I/O Design Pattern.
The name implies that this is the way to get async done in .NET. After all, that’s what “pattern” means — a customary way to solve a particular problem.
Recently, the term lost its meaning since literally everything is a pattern now. Small solutions, big solutions, even custom solutions are patterns now. Sometimes, when I hear developers talk I can’t help but think of the scene from Being John Malkovich where John Malkovich gets inside his own head:
Let’s get back to the article. There are two big things that are wrong it.
1) The whole point of async is to avoid thread blocking. It’s in the first words of the Wikipedia page: “Asynchronous I/O, or non-blocking I/O…”
Non-blocking IO. Instead of blocking your thread, you queue an operation (or a set of operations) and allow thread to do more work. You don’t sit around and wait, you go and start processing other requests. When the async operation is completed you will be called via a callback. That’s the whole point. Fire and forget, until it’s done.
It is easy to understand if you are doing async right. A pure async application does not need to start more OS threads than physical CPU cores. While you can start more threads to increase responsiveness in certain scenarios (long calculations, for instance) it will not improve your RPS.
2) The code author uses to illustrate his “pattern” is a damn good example of how not to write code.
Take a look at this code from MultiHostLookup method (this method queues multiple async requests and waits for the completion):
lock (addressList)
{
// ensure all lookups have returned, otherwise wait
while (addressList.Count != hosts.Count)
{
Monitor.Wait(addressList);
}
}
So we lock addressList and we wait under the lock. Well, guess what happens when an operation is completed? According to the “pattern” this is what happens in GetHostAddressesCallback method:
// we need to ensure updates to the address list are threadsafe
lock (addressList)
{
addressList.Add(address);
// notify listeners that another address has been added
Monitor.PulseAll(addressList);
}
The thread will try and acquire a lock on addressList. Which, if you remember, is locked by the thread executing endless while loop in MultiHostLookup.
One thread waits for another under a lock. The other thread uses the same lock to signal its completion back. A wonderful example of “how to deadlock your threads” pattern.
Here is a simple rule for writing multi-threaded apps: NEVER EVER WAIT UNDER A LOCK. That’s a sure way to get your application deadlocked.
It is extremely frustrating to see such async 101 mistakes. IO Completion Ports have been around since NT 3.5- more than 15 years! If you are interested in how to actually write high performance async applications, that’s a good place to start getting the concept.
Interesting finds. Code to look at.
Lately, my news feed and I have been out of touch. Let me elaborate.
Most of the links I’ve seen recently could be put into two large categories: “mobile phones” and “I wonder what people smoke”. I am not a mobile developer and while I keep an eye on the mobile world, it’s a bit outside of my area of expertise. Most of the other stuff … well, I am not even sure what to tell you. It’s illegal to have weed this strong here.
For instance, one of the blogs I follow is Jason Haley. He posts links to other blogs, calls it “Interesting Finds”. One of the sub sections is called “Code to look at”. Well, take look at the today’s catch:
1) Fluent.Xml.Linq – Exploring the limits of C# syntax.
Not sure why it has XML and LINQ in the title. The article is about 5 different ways to include HTML in your C# code. Maybe it’s just me, but I have never ever needed to add HTML to my C# code. Sometimes I need to add code to my HTML (to control its generation), but never the other way around.
The brightest part of the article is a quote by Martin “UML” Fowler: One of the problems of methods in a fluent interface is that they don’t make much sense on their own. Isn’t it shocking? Fowler says there is a problem with something that doesn’t make much sense! Who would have thought.
2) Yet Another Singleton Implementation in .NET 2.0
In the very first sentence the author asks the most important question: Many of you aware what is Singleton Pattern is. For whom don’t know what is Singleton pattern is?
Lucky, Bill Clinton has already answered this deeply philosophical question back in his 1998 Grand Jury testimony: It depends on what the meaning of the words ‘is’ is.
3) JavaScript code to determine when DayLight Savings Time (DST) occurs.
This article gets you one Google question closer to the solution for a problem you are unlikely to have.
4) FileSystemWatcher – Pure Chaos (Part 1 of 2).
Yet another background thread that monitors file system changes. It’s been in WIN32 API since, well, WIN32 API. Thrilling.
5) User Story Source Code Layout with MSpec.
public class I_transfer_an_amount_less_than_my_savings_account_balance
Naming_classes_like_this_is_bad_for_your_Karma.
Seriously. Never ever name classes like this. No matter what the reason is.
6) Diagnostic Trace Display Using WPF.
A 10 line System.Diagnostics.TraceListener implementation.
Have a nice day!
Google Buzz
I really like Google Buzz. I’ve been a user of Google “Leaky” Talk, for years now and I have most of my friends and co-workers on it, which makes my following/followers list instantly populated with people I communicate the most.
No message length limitation is always good. 140 characters limit on Twitter always felt artificial. The ability to attach photos and links is something I’ve been looking forward to as well. Overall, it seems like a good quality product that will gain some momentum eventually. Twitter’s Fail Whale is pretty annoying, especially when something big is going on, like the Super Bowl.
