I got to work on a fun DCR with Chris Brumme back around the time we were shipping Whidbey Beta2. (DCR means Design Change Request, essentially an unplanned change to the design of a component.) We went back and forth as to whether or not to release it with Beta2, but given that the implementation would have been right up against our lock down period, the risk was too high. Thus, it’ll first appear in our next CTP, RC, or whatever release comes out before Whidbey RTMs.
The CLR was designed to work very well in a COM world. This design choice is not at all surprising given the history of programming on Windows, and that the CLR began life as the COM+ 2.0 Runtime (among other temporary names). When it comes to concurrency in this world, however, there’s a whole host of crap that can go wrong. Thankfully most of the time it doesn’t.
I’ve spent a bit of time this weekend on my concurrency talk for PDC. It’s taking me longer than expected, mostly because I’m writing “a story” up front… before I even think about touching PPT or writing code. The end result will be a great story to tell captured in a paper and–so that I have a convenient way to guide me through the talk–a slide deck. Too many people use PPT as a crutch for presentations, and most of the time it shows.
When access to a location in memory is shared among multiple tasks executing in parallel, some form of serialization is necessary in order to guarantee consistent and predictable logic. Furthermore, in many situations, a number of such reads and writes to shared memory are expected to happen “all at once,” in other words atomically. Serializability and atomicity are both often implemented using mutual exclusion locks. This is bread and butter stuff.
Those guys on the VC++ team have been busy workers. In the Whidbey release of C++/CLI (was Managed C++), they’ve added a whole big batch of new features. The best part? Some of these are things you simply can’t do in C#. Put another way, C++/CLI exposes a larger set of the underlying features that the CTS/CLI has to offer.
I remember the distinct feeling I got the first time I entered ‘csc.exe’ at the command line and realized that the C# compiler wasn’t doing any exception checking for me. Surely I had done something incorrectly. Or so I thought. After a bit of time searching around, asking around, and banging my head against the wall (still got the fracture in my skull), I came to the realization that C# had chosen not to support checked exceptions. Hmm.
My implementation of Software Transactional Memory (STM) on Rotor is coming along nicely. I’ve taken a different approach than most, actually taking advantage of the JIT and EE to do my dirty work for me. Some prefer to stay inside the cozy confines of managed code, but I’d like to understand better the impact that my design might have on the non-transactional runtime. I admit that my approach is likely not viable for real commercial use mostly due to its intrusive nature. Unless all code were transactional, which it’s not. But this is partly what I’d like to understand better.
Structured exception handling and all of the challenges associated with it aren’t new topics about which developers must worry. I was flipping through my copy of The C++ Programming Language (3rd Edition) this morning and ended up rediscovering Appendex E on C++ Standard-Library Exception Safety. Understanding what consistency and failure guarantees you intend to make with your library and then actually making them, knowing what to expect from a pre-written library and when and how to program defensively against it, and all such related topics were challenging with C++ and remain a challenge with C#. It’s amazing how many of these things are directly transferrable between technologies.
I was on an email thread with a customer earlier today, and the topic of fibers came up. More generally, the need to schedule lightweight tasks for simulated concurrent execution. The thread pool is fairly heavyweight, doesn’t offer much flexibility in the way of scheduling, and admittedly just doesn’t quite cut it for many scenarios. We’re looking hard at how best to improve the thread pool support in Orcas (that’s Whidbey + 1)–especially in the area of better control over the scheduling policy–so I’d love to get any feedback you might have.
Don’s kicking butt over there with lots of experimentation with closures and iterators in C#. Sam has commented and seems to be impressed with C#’s new evolutionary direction. I am too.