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.
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.