Bill Blogs in C#

Sara Ford has been posting tips about the VS 2005 editor.  Today's tip(http://blogs.msdn.com/saraford/archive/2007/09/28/did-you-know-how-not-to-accidentally-copy-a-blank-line.aspx) shows a nifty little setting that disables Copy and Cut when you're on a blank line with no text selected.

 Why is that useful?

Well,how many times have you cut some code from one location, tried to put it somewhere else, and hit Ctrl-C instead (because C is so conveniently located right next to V).  Argh.  Three Undos later, and you're back to work.

Dianne discusses this at length here, but I want to make sure than anyone subscribing to my blog but not hers knows about it as well.

One of our goals in having physical office space was to facilitate the growth of technical people in our area. One way that we intend to do that is to host Lightning Talk Fridays, starting twice a month.

Obviously, Lightning Talk Fridays take place on Friday. These events are open to the public. You can signup to give a talk, or look at the existing schedule here: http://srtsolutions.com/forums/32.aspx I'd encourage you to participate and share your knowledge.

Technorati Profile

Just cause someone needs to know.

A friend passed along this announcement about the Michigan Interactive Designers meeting. The group is interested in discussing topics relating to developing engaging user interactions using leading edge UI tools. (And, Bombadil's has great coffee).

September Meeting Coming Up

Saturday September 22, 2007, Bombadil's Coffee Ypsilanti
 
Our next meeting will be held  Saturday September 22, 2007. Time 3:00pm to 5:00pm. We will be discussing and touching on the following Topics.

• Blend September preview new animation features reviewed (Vetex Animation, Font Embedding, User Controls)
• Visual Studio 2008 beta 2
• Silverlight 1.1 Alpha and the HTMLTextBox Control
• Astoria Data Services and Entity Modeling
• ASP.NET AJAX- Update for iPhone
• Silverlight Development Models: Targeting your application to the right release..
• Silverlight and Rich Media (creating cool effects with the VideoBrush).
• Programming Silverlight in C# and VB and dynamic languages.
• Silverlight and HTTP and Web Services Accessibility
• Silverlight Controls in XAML and extending the controls class
• Silverlight 1.0, 1.1, .NET 3.0, .NET 3.5 Hitting your design targets... How to plan for a release while staying in sync with Microsoft's release schedule.
• Armory Arts Update
• Converting Flash Animations to Silverlight.
• Book Review: Expression Blend Bible

Monthly Prizes Awarded
We took a break August, but are back for September with a great new meeting..
If you missed out on any of the presentations this month or the meeting, you were definitely missing out.
Next Meeting Date: September 22, 2007
Locations: Bombadil's Coffee Shop 3:00 p.m.- 5:00 p.m.

Our newest senior consultant, Patrick Steele, is now blogging here at SRT Solutions. He has a depth of technical knowledge, and he communicates that knowledge to his readers very effectively.

It's worth reading. Often.

And, check out the pictures of the office that Patrick took at the last Ann Arbor .NET meeting.

I got the following questions in an email recently on C#:

1. Is C# going to be a fully supported package for the long term?  I was going to start a new program development using C# but if there is little activity from Microsoft I will consider alternatives.

   2)       When a new C# development package will be available from Microsoft?

The second question is simpler, so I'll answer that first. Somasegar posted the official announcement here. Visual Studio 2008 (previously codenamed Orcas) will be released February 27^th, 2008. If you read his entire blog entry, you will see that VS 2008 is planned to go to RTM toward the end of this year.

If you can't wait, you can get Beta 2 here.

The first question forces me to make some speculation. By looking at the new features and concepts in C# 3.0 (which is part of the VS 2008 release), it's clear that the C# language team is not done coming up with new ideas. I know that whenever I talk with members of the C# team, I give them feedback about features I'd like to see, or programming idioms I wish were easier. Sometimes, they even ask for that feedback before I give them my thoughts.

Languages do mature, and fewer features are added to them over time. But, that does not mean they cease to be relevant. The C++ language is still very vibrant, and a new standard is in the works. (A draft standard was published in June of 2007.) I don't believe C# has reached that level of maturity yet. I expect that there will still be a number of new ideas that make us go "wow" when we see them. (And that's after VS 2008 is released). In fact, I think your question shows that C# is just starting to mature. It's the first time I've been asked is C# is getting old. Most of the people I've worked with that are concerned about C# in a new development are worried that C# is too young, and not yet ready for serious work. Obviously I think we're past that point, but I don't believe C# has even reached its prime, let alone its decline.

My last column has generated more questions again:

I am reading your article, "Write code for a multithreaded world". It is very interesting.
Could you please go more detail about Locking the this object is always a bad idea?

The referenced article is here.

Well, the problem is one of how to manage the complexity involved with locks. When you say lock (this), the visibility of the object being locked matches the visibility of the class. So, if you have a public class, the object being locked is visible from everywhere.

Let's say you have a deadlock issue in your code. Well, if your locking objects are all private to a class you have done quite a bit to limit where you need to look. Chances are some method in your class acquires the lock, and then raises an event while holding the lock. The event handler may switch threads (through Control.Invoke) and that handler calls another method that tries to acquire the same lock.

It's still a tough problem, but there are a small number of ways to hurt yourself, and when you do, you've got a bounded set of code (that one class) where you need to look.

On the other hand, suppose a class is littered with lock(this) and you have a deadlock. Now, you need to search the entire codebase for lock constructs and examine each one to see if it's locking that object. Instead of one class, you could have hundreds of thousands of lines of code to search. It's a needle in a haystack, and the likelihood of finding the cause is the same.

So, prefer locking on a private member variable rather than locking this.

I received a couple reader questions from my last Visual Studio Magazine article (link here). I thought they would be of general interest, so I'll answer them here:

1- you write: "The new object is created, and initialized before it is assigned to the internal member. This ensures that the entire object is updated in one operation." Are you saying that no context switch happens during class construction?

Or do you mean that it doesn't matter if it does, the object would remain consistent because the class has no mutation operations and the assignment to variable is atomic?

A context switch can happen during the constructor, but it doesn't matter because you can't manipulate the object until the constructor has completely finished. For example, if I write:

MyType foo = new MyType();

foo.DoThatVoodooThatYouDoSoWell();

There may very well be context switches that happen while MyType's constructor is executing. But it doesn't matter, because the last thing that happens is that foo is assigned to that new MyType. Until that assignment happens, no code (in any thread) can modify or access foo. So we're ok. Once construction has happened, immutability matters because now more than one thread may access foo. Context switches during any arbitrary mutator method on foo may leave the object in an inconsistent state.

2- I believe the consensus is that volatile variables are thread-safe, but what does that mean? Aren't all types (at least integral ones) thread-safe on atomic operations (i.e. assignments)?

That's true for most integral types. There are two actions that can cause problems. First, suppose a type is large enough that it takes more than one machine instruction to perform the assignment. (Consider a point with X,Y coordinates). That's two machine instructions to do the assignment (Assign X, Assign Y). A context switch between the two assignments means that you've got the point in an inconsistent state.

Secondly, consider an assignment where the lvalue also appears as the rvalue. The classic example is a bank balance:

balance = balance + depositAmount;

In machine instructions this will equate to (roughly)

1. Fetch balance from memory and store in a register
2. Put depositAmount in another register.
3. Perform the add
4. Put the result back in the memory location used for the balance

If a context switch occurs anytime after 1) and before 4), you run the risk of performing the calculation on the wrong value. Even though the assignment is atomic, the entire operation is several actions.

Thanks for the questions, and I hope that helps.