Thread synchronization of non-atomic invariants in .NET 4.5

Now that we’ve seen how a singular x86-x64 focus might affect how we can synchronize atomic invariants, let’s look at non-atomic invariants. While an atomic invariant really doesn’t need much in the way of guarding, non-atomic invariants often do.  The rules by which the invariant is correct are often much more complex.  Ensuring an atomic invariant like int, for example is pretty easy: you can’t set it to an invalid value, you just need to make sure the value is visible.  Non-atomic invariants involve data that can’t natively be modified atomically.  The typical case is more than one variable, but … Continue reading Thread synchronization of non-atomic invariants in .NET 4.5

Thread synchronization of atomic invariants in .NET 4.5 clarifications

In Thread synchronization of atomic invariants in .NET 4.5 I’m presenting my observations of what the compiler does in very narrow context of only on Intel x86 and Intel x64 with a particular version of .NET.  You can install SDKs that give you access to compilers to other processors.  For example, if you write something for Windows Phone or Windows Store, you’ll get compilers for other processors (e.g. ARM) with memory models looser than x86 and x64.  That post was only observations in the context of x86 and x64.  I believe more knowledge is always better; but you have to … Continue reading Thread synchronization of atomic invariants in .NET 4.5 clarifications

Thread synchronization of atomic invariants in .NET 4.5

I’ve written before about multi-threaded programming in .NET (C#).  Spinning up threads and executing code on another thread isn’t really the hard part.  The hard part is synchronization of data between threads. Most of what I’ve written about is from a processor agnostic point of view.  It’s written from the historical point of view: that .NET supports many processors with varying memory models.  The stance has generally been that you’re programming for the .NET memory model and not a particular processor memory model. But, that’s no longer entirely true.  In 2010 Microsoft basically dropped support for Itanium in both Windows … Continue reading Thread synchronization of atomic invariants in .NET 4.5

Visual Studio 2010 Best Practices published

Most of my spare time in the last few months has been taken up by writing Visual Studio 2010 Best Practices.  This has now been published and is available through publisher (no longer pre-order) at http://bit.ly/Px43Pw.  The pre-order price is still available for a limited time.  Amazon still has it out of stock; but $39.99 at http://amzn.to/QDDmF7. The title of the book really doesn’t do the content justice.  Least of which is “Best Practices”.  Anyone who knows me should know I don’t really like that term.  But, hopefully those looking for best practices will read the book and learn from chapter … Continue reading Visual Studio 2010 Best Practices published

Automated Testing Isn’t Just for Business Logic

I had a conversation with Kelly Sommers the other day that was partially a short support group session on the annoying tendencies of development teams to completely lose focus on the architecture and design principles of a system and let the code base devolve into a ball of muddy spaghetti. One particular area that we discussed, and it’s one area I’ve detailed elsewhere, has to do with layers.  Our gripe was that developers seem to completely ignore layering principles once they start coding and introduce cycles, put things in the wrong layer, etc.  A brief recap of layering principles:  Types … Continue reading Automated Testing Isn’t Just for Business Logic

Dispose Pattern and “Set large fields to null”

I was involved in a short side discussion about “should” fields be set to null in the Dispose method(s).  I’m not sure what the impetus of the question was; but, if you read through the dispose pattern MSDN documentation (in most versions I believe) there’s a comment // Set large fields to null. in the implementation of the virtual Dispose method within the if(!disposed) block and after the if(disposing) block.  But, that’s the only reference to setting fields to null during dispose.  There’s nothing else that I’ve been able to find in MSDN with regard to setting fields to null. … Continue reading Dispose Pattern and “Set large fields to null”

“Virtual method call from constructor” What Could Go Wrong?

If you’ve used any sort of static analysis on source code you may have seen a message like “Virtual method call from constructor”.  In FxCop/Visual-Studio-Code-Analysis it’s CA2214 “Do not call overridable methods in constructors”.  It’s “syntactically correct”; some devs have said “what could go wrong with that”.  I’ve seen this problem in so many places, I’m compelled to write this post. I won’t get into one of my many pet peeves about ignoring messages like that and not educating yourself about ticking time bombs and continuing in ignorant bliss; but, I will try to make it more clear and hopefully … Continue reading “Virtual method call from constructor” What Could Go Wrong?

Software Design and First Principles–Part 0: Concepts of Object Orientation

I often compare software development with building houses or woodworking.  I sometimes even compare software development with the vocation of electrician.  In each of these other vocations, craftspeople need to go through a period of apprenticeship and mentoring before being “allowed” to practice their craft.  In each of these vocations there are a series of rules that apply to a lot of the basics of what what they do.  With building houses there are techniques and principles that are regulated by building codes; with electricians there’s techniques and fundamentals that are effectively regulated by electrical codes and standards.  It’s one … Continue reading Software Design and First Principles–Part 0: Concepts of Object Orientation

The Flawed Eventually-upgrade Software Model

I think Windows XP was the first real release of Windows–it had finally gotten to a usability and stability point that people could accept.  The Microsoft support model changed shortly after Windows XP was released to basically support any piece of software for as long as ten years (if you paid extra for support roughly 2 years after a successive version was released). To paraphrase a famous law: software becomes obsolete every 18 months.  That was true for a long time; but hardware and software isn’t improving at that rate any more.   Software has basically caught up with existing hardware … Continue reading The Flawed Eventually-upgrade Software Model

The Rat-hole of Object-oriented Mapping

Mark Seemann recently had a great post that, as most of his posts seem to do, challenges the average reader to re-think their reality a bit.  The post is titled “Is Layering Worth the Mapping”.  In the post Mark essentially details some of the grief and friction that developers face when they need to decouple two or more concepts by way of an abstraction. Mark takes the example of layering.  Layering is a one way coupling between two “layers” where the “higher-level” layer takes a dependency on abstractions in a “lower-level” layer.  Part of his example is a UI layer … Continue reading The Rat-hole of Object-oriented Mapping