Event-Driven Programming (Message from the CTO, newsletter 47)

You may have noticed that I’m on a JavaScript kick at the moment. My introduction to node.js and real async programming came out of that and I’m still amazed at it all.

photo © 2006 Jie Qi | more info (via: Wylio)Event-driven programming

Event-driven programming? Haven't we been doing that since the dawn of time? Well, since Windows 1 at any rate? What's possibly new that we can talk about?

Let me approach it like this: multithreaded programming is hard, very hard. It suffers from data access and sharing issues, it seems to function under the Observer effect — the observer observing the system can change its state — leading to what is colloquially known as Heisenbugs. Yet, given the state of play of the CPU hardware at the moment, surely writing multithreaded programs is the only way to go to get the performance we need?

The answer is, surprisingly, no. Consider the new async functionality coming in C# 5.0. For a certain set of problems, the performance of a program is dependent on its I/O. Far too often a thread will sleep waiting for a read or write request to be completed and processing to continue. The C# 5.0 async functionality is designed to produce a simple way of doing asynchronous programming or "evented I/O". This allows us to write programs that do I/O in a fairly normal easy-to-read manner but that function as small request tasks with callbacks called when the request has completed. This, in turn, ensures that the CPU is being used at full-speed with minimal thread switching. Since the majority of work is being done on one thread, there are no real issues with the sharing and concurrency of data.

In the server world as well, there's a new player in town called node.js. Node is an encapsulation of the Google V8 engine that provides an evented I/O environment for JavaScript. On the server, not on the client. This environment allows programmers to create web servers (and other kinds of servers like ftp, irc, and the like) that scale to many concurrent users easily. The reason for the scalability is that the main process never waits. All I/O is done through issuing a request to a hidden event loop, with a callback being notified (and queued on the event loop) on completion.

So, I would recommend that you read up on asynchronous programming and evented I/O. You may be needing it sooner rather than later.

(You can watch the video here.)

Part of me wonders what a node-ified ASP.NET runtime would look like.

By the way, I shall be at Tech·Ed in Atlanta next week. If you’re going too, pop by the booth to say hello and so we can talk about DevExpress’ products and services.

Free DevExpress Products - Get Your Copy Today