This session by Joe Duffy had more practical advice about programming with concurrency. Some highlights:

• It is important to maintain invariants (“assumed conditions in your code”), even in the face of exceptions.
• Asynchronous exceptions like thread aborts can happen almost anywhere, which can make invariant maintenance difficult, but .NET prevents them from being thrown from certain sensitive areas, such as catch/finally blocks, static constructors, and native code.
• Generally speaking, when you write a class, you should make any static state thread-safe, but require your client to lock access to your class instances, since you can’t predict their concurrency needs.
• Always protect shared memory with locks. In .NET, locks do more than prevent concurrent access; they also guard the code against hardware instruction reordering, etc.
• In the future, parallel programming will be the only way to leverage the increasing speed of computers, as the speed of a single CPU is nearing its physical maximum.

This was a good session by Jan Gray on the fundamentals of using concurrency in software development. Why bother with concurrency? For one, hanging the application is as disruptive as a crash, so it is important to free up the user interface thread by delegating work to other threads. You can also improve the user experience by allowing the user to see the status of the work, examine partial results of the work so far, and cancel the work if necessary.

Another use of concurrency is to increase performance by spreading the work across multiple processors. Of course, measurement is the key here; before adding the complexity of concurrency, make sure that you’re already pegging the CPU, and make sure that your algorithms are already fully optimized.

This session provided a number of tips:

• Server applications are often already highly concurrent, since each client gets their own thread, and SQL can distribute a single database query among multiple processors.
• OpenMP exists for doing straightforward parallelism in client applications. (It is supported by Visual C++ 2005.) Otherwise, the classic tools are threads using shared memory protected by locks.
• The standard techniques for protecting shared memory from conflicts, in increasing order of difficulty, are confinement (sharing as little memory as possible), immutability (not allowing writes to the shared memory), and synchronization (locking access to the shared memory).
• There are three primary goals when writing concurrent code: safety (identifying and holding “invariants” in shared data), liveness (avoiding deadlocks – two threads waiting for a lock the other holds), and efficiency (making the code as parallel as possible, generally by waiting as little as possible).
• In most cases, the thread pool is best for doing work in parallel, since it may not have the overhead of creating a new thread. In .NET, use ThreadPool.QueueUserWorkItem or BackgroundWorker.
• In .NET, use the Monitor class for shared memory management. Two threads interacting via shared memory use Monitor.Enter and Monitor.Exit to protect the memory. If one thread needs to wait for the other, Monitor.Wait releases the lock until the other thread calls Monitor.Pulse and releases its lock.
• If necessary, consider other classes in the System.Threading namespace, such as WaitHandle, Auto/ManualResetEvent, Mutex, and Semaphore. Rarely consider the Interlocked methods, ReaderWriterLock, Thread.Interrupt, and asynchronous delegates.
• Lock all writable shared state over the entire invariant, using private lock objects (not the instance or type object).
• Avoid calling “third-party” code while you hold a lock, including overridable methods.
• Use asynchronous I/O, e.g. Stream.BeginRead in .NET.

My first session at PDC 2005 was “Getting Users to Fall in Love with Your Software” by Hillel Cooperman. This session wasn’t really about Microsoft technology, but about ways to ensure that your users have a positive emotional reaction to your software. Unfortunately, there were no easy answers given here. Basically, you need to understand your customers, watch them in usability studies, anonymously instrument their use of the software, etc. Software products should be friendly, forgiving, and rock-solid.

Of course, there are other factors at play here, particularly the cost in time and money of doing all of that research and subsequent development. When retrofitting an existing software package, you also need to consider the amount of retraining that will be necessary.

The application that they developed to demonstrate these principles is a photo album application called Microsoft Max. If you’re curious, and dare install the WinFX September CTP, go check it out.

Basically, this session was a good reminder that we need to spend all of the time and money we can afford to eliminate the many negative emotional reactions that our products create in our users and actively strive toward a positive experience. Like most aspects of software development, there’s never a point where you’ve reached perfection, but most software teams should be spending more time in this area than they are.

It was, of course, fun to watch Bill Gates give his keynote on Day One. The video segment was entertaining, though a bit lost on me – it was a spoof on Napoleon Dynamite, which I have not seen. Jim Allchin’s keynote was also good; it was fun to see Windows 1.0 running on an old IBM XT. He claimed that 475 million new PCs will ship in the two years after Windows Vista is released; I reckon I’ll be one of the buyers. The best part of the keynotes on Day One was the demos. We saw Windows Vista and Office “12” and Superfetch and “Atlas” and WPF and WCF and LINQ, etc. Great stuff.

The keynotes on Day Two were a bit less interesting. The first half wasn’t too bad; we saw demos of Windows Workflow Foundation and the new Expression products for designing the next generation of cool user interface. The second half was, unfortunately, one of the most boring demos I’ve ever sat through, being about two technologies I (still) know nothing about, InfoPath and SharePoint.

I had low expectations for the keynote on Day Three, but it turned out fine. It was all about the new features coming for Windows Server, including better debugging of Web applications, remote computing, the new console, and IIS improvements, particularly for ASP.NET applications.

The “trouble” with the PDC is that it’s about products that won’t ship for a year or two; I’m ready now!

Last week, I went to the Microsoft PDC with three coworkers and had a great time. They keep you much too busy to blog while you’re there, but that shouldn’t stop me from blogging it now that I’m back, right?

The conference really was excellent. For the most part, it was well-organized and well-executed. Even the name badge was great, complete with a pen and an easy-to-access mini-guide of the conference for helping you keep track of the agenda, find your next session, etc. Food and drink was available everywhere, at all times, including three square meals each day. Lots of software and “swag” was distributed by Microsoft and by various sponsors and advertisers. An evening of exclusive access to Universal Studios was simply the icing on the cake. The PDC isn’t cheap, so it’s hard to measure whether it is “worth it,” but it was, at minimum, a great experience. Hopefully I’m better prepared to face the future of Windows application development…

I bought the last copy of Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams at the PDC so that I’d have something interesting to read on the trip home, and I was not disappointed. I find myself in agreement with nearly all of the guidelines; widespread adherence to them even when writing small libraries would improve overall code quality. Of course, it’s much more interesting to highlight the areas that I don’t agree with, so I’ll first make myself clear – I highly recommend this book to anyone writing code that uses the .NET Framework or any similar object-oriented framework.

One classic source of disagreement is in the use of Hungarian notation; I use a mild form of that notation that I feel greatly improves code readability. The guidelines only prohibit the use of these identifier “warts” on the public API, which would be fine, except that method parameter names are shared by the API (which shouldn’t use them) and the implementation (which should, if the rest of the implementation does). So, what to do? Since there’s no easy way to have my cake and eat it too, I just use Hungarian with parameter names, and hope that my clients will forgive me.

I’m not fond of the event pattern where a protected virtual method is defined that raises the event. It’s not clear to me why derived classes should be able to suppress the raising of events; I prefer virtual methods to always be abstract or empty, so that derived classes don’t have to call the base-class implementation at all. I like adding the virtual method, so that derived classes don’t have to add event handlers to their own events, but I tend to call the virtual method and then raise the event.

Speaking of parameter naming, and speaking of events, I really don’t like the convention of calling the EventArgs parameter e. I use args.

Finally, I only agree with about half of the coding style conventions listed in Appendix A:

• They seem to have something against spaces, which are important for readability, particularly if you’re using a proportionally spaced font. (You really should be writing code in Verdana 8pt if you’re not already.)
• I love omitting braces around single statements; I don’t buy the “readability and maintainability” argument, particularly when you put the opening brace on its own line (which they don’t).
• Tabs are way better for indentation than spaces.
• I’ve never understood why private fields should go at the top of a class declaration. All other private members go at the bottom, and for good reason; why not fields? Otherwise, their recommendation to group members is good, though I prefer logical ordering to alphabetical ordering when practical.

I’ll have to publish my own coding style conventions one day. If you’re really curious, just look at code samples elsewhere on this blog…

And in case you skipped down to the bottom, let me reiterate – you should read this book!

I'm still waiting to find a good introduction to Windows Communication Foundation (aka WCF aka “Indigo”). I want an article or book that explains even the simplest foundational concepts; something for a client application developer like myself who is realizing that his code will eventually have to talk to that newfangled “Internet” he keeps hearing about.

A recently published MSDN article comes close, but it still uses too many big words. What little I understand sounds compelling, though, so I'll keep waiting...