Layers of Abstraction

One of the questions I often hear when I tell someone that I work on ADO.NET is “Is that still alive?” And, while ADO may be long gone, ADO.NET is today one of the most popular ways to connect to SQL Server and is the underlying layer beneath many (if not all) .Net Object Relational Mappers (ORMs) like Entity Framework (EF). However, it is because of these ORMs that you never hear about ADO.NET – it is no longer the “new, sexy” thing (and we don’t have product names like “Magical Unicorn Edition”). This does not mean that ADO.NET is simply becoming a framework to build ORMs, the world is a bit more complicated than that…

One thing that ORMs do well is to allow developers to quickly and easily get a database up and running, and then to get access to the data that is sitting there. For instance, the tooling in EF allows you to quickly create a model, deploy that to a database, code some LINQ (with its IntelliSense goodness) to grab some data, and then manipulate that data as an object. ORMs also make prototyping and rapid development easier as the model they generate can be updated from the database and any changes in the database schema will then show as compiler errors since the corresponding object in that model has now changed as well. One of the problems with EF, and ORMs in general, is that the extra layer of abstraction adds a performance cost, and while EF has been working to reduce that, you can see from the graph below that hand-coded ADO.NET is vastly quicker – so, what to do?

Opportunity Cost

As with any technology choice, you need to carefully considered what each option offers, and what each options costs. EF (and ORMs) offer quick and easy coding at the cost of the application’s performance. For some projects this may be fine – the developers may be too busy to consider hand-coding, or the cost of additional servers may be much less that finding, hiring and onboarding additional developers. Alternatively, ADO.NET may be chosen if the application is large enough that any percentage performance increase is a significant cost savings, or that the turn around time for a single database transaction is critical and every microsecond counts. Just to emphasize the point – remember that ADO.NET is an abstraction from the TDS protocol. There may be developers for which they performance is ultra-critical and they would rather hand-code TDS packets and communicate with SQL Server that way (which is entirely possible, since TDS is a documented protocol).

At the end of the day, you need to choose what makes sense to you and to your business plan – whether that means hand-coding ADO.NET, utilizing an ORM or a mix in between (like starting with an ORM and then hand-coding performance critical queries).

(As a side note: .Net 4.5 Beta has arrived! And ADO.NET has some new features that I will be posting about soon – in the meantime download the Beta and get coding, and be sure to log any bugs or suggestions on the Connect site or the Forums)

SpotTheDefect[0].Answer[2]

Over the past few weeks I’ve been covering various ways to fix a race condition bug. Answer 0 was a very basic solution where we were using a lock to serialize access, and with Answer 1 we significantly improved the performance without sacrificing safety by using the “Copy, Check, Continue” pattern.

However, what you may have noticed from the code is I had a variable called _disposed that I was using it to indicate that we have nulled out _foo – but what if _foo was IDisposable? And we had to make sure that we don’t call any method on it after we disposed it?

But where is the fun in that?

The most obvious thing that we could do is to simply use Answer 0 – by putting locks around the  usage of _foo we can be certain that _disposed accurately reflects if _foo has been disposed or not, but again this is a trivial solution that has a performance cost.

An alternative is to implement Answer 1 and then to catch any ObjectDisposedExceptions that are thrown. This allows us to be “lazy” with our thread safety, and so get back some performance. The problem with this solution is that we can’t be sure that using _foo will throw an ObjectDisposedException: it is entirely possible that _foo will null out one of its fields and we would end up with another race condition similar to the one we were originally trying to solve; or it may just throw the wrong exception type (for example, using a closed\disposed SqlConnection will result in an InvalidOperationException).

Teamwork is key

What makes Answer 0 safer compared to Answer 1 is that both threads are aware of what each other are doing, and they are coordinating their actions. If we were simply concerned that access to _foo would be serialized under a lock, then we could switch to a ReaderWriterLockSlim, and have Thread1 obtain a ReadLock and Thread2 obtain the WriteLock. However, if there are few threads trying to access _foo at once, then you’ll probably find that an uncontested lock provides better performance than the ReaderWriterLockSlim.

An alternative to this is to implement similar mechanics to a ReaderWriterLockSlim but using faster primitives without any locks. Firstly, there are two things our ReaderWriterLockSlim alternative needs to keep track of: the number of readers in the reader lock, and if the writer lock is in used – this suggests that we will need an integer for the readers, but a bool for the writer. Secondly, if the writer lock is held, then no readers may enter the lock; but the writer can not do its work until all readers have finished reading. So, putting this together, we already have our writer lock bool (_disposed), and we can introduce the int for the readers (_activeReaders). Readers must then Increment _activeReaders when they start, and decrement it when they end – but must not do any work if _disposed is true. Similarly, the writer set _disposed to true when it starts and then waits for the readers to finish (i.e. _activeReaders becomes 0).

There are a couple things that you should note about this solution:

• We expect there to only ever be one thread “writing” at a time (otherwise you need to synchronize access to _disposed – or switch it for an integer, increment it and then only disposed if it equals 1)
• Once we have “written” no other locks can be taken again
• I’ve used Interlocked.Increment\Decrement to manipulate _activeReaders (this is because incrementing\decrementing is not guaranteed to be atomic)
• I’ve had to disable warning CS0420: “a reference to a volatile field will not be treated as volatile”, but it is safe to do so because the Interlocked APIs are “volatile aware”.

So here is the revised solution:

using System;
using System.Threading;

namespace SpotTheDefect1
{
    class Program
    {
        private static Foo _foo = new Foo();
        private static volatile bool _disposed = false;
        private static volatile int _activeReaders = 0;

        static void Main(string[] args)
        {
            Thread thread1 = new Thread(Thread1);
            Thread thread2 = new Thread(Thread2);

            thread1.Start();
            thread2.Start();

            thread1.Join();
            thread2.Join();
        }

        private static void Thread1()
        {
            // Check first to avoid unneccesary work
            if (!_disposed)
            {
                // Warning CS0420: a reference to a volatile field will not be treated as volatile
                // We can safely ignore this because the Interlocked APIs are volatile aware
                #pragma warning disable 0420
                Interlocked.Increment(ref _activeReaders);
                #pragma warning restore 0420

                try
                {
                    // Check again in case we were disposed after doing the increment
                    if (!_disposed)
                    {
                        _foo.Bar();
                    }
                }
                finally
                {
                    // Warning CS0420: a reference to a volatile field will not be treated as volatile
                    #pragma warning disable 0420
                    Interlocked.Decrement(ref _activeReaders);
                    #pragma warning restore 0420
                }
            }
        }

        private static void Thread2()
        {
            Console.WriteLine("Disposing");

            // Indicate that we are disposing and then wait for readers to complete
            _disposed = true;
            SpinWait.SpinUntil(() => _activeReaders == 0);

            _foo.Dispose();
            _foo = null;
        }

        private class Foo : IDisposable
        {
            public void Bar()
            {
                Console.WriteLine("Hello, World!");
            }

            public void Dispose()
            {
                Console.WriteLine("Foo has been disposed");
            }
        }
    }
}

Getting the disassembly and IL for a Jitted\NGENed .Net method using WinDbg and SOS.dll

If you didn’t understand the title, then this post isn’t for you.
If you think you understood, and you think that this may help you with your debugging – then turn back now, you’ve gone completely the wrong way.

I’ve put this disclaimer here since, unless you are interested in how the JIT works (in which case, skip this and read on!), the only reason you are getting the assembly from the JIT is because you believe that the JIT compiled something incorrectly (or, at least, that was why I was investigating this – although it turned out that we were hitting an issue due to Out of Order Execution which lead to a race condition which had a window of a couple of CPU instructions – which just goes to show how awesome our stress test is).

As a note (if you want to try this at home) this uses the SpotTheDefect[0] code, which has been modified to initialize _foo to null (ensuring that the application crashed) and I’m trying to get the IL and disassembly for the Thread1 method

So, first off, we need to load our good friend SOS:

0:004> .loadby sos clr

Then we can find the method table for the class that contains the method we want. In my case, I’m looking for the Program class which is under the SpotTheDefect1 namespace in the SpotTheDefect1 assembly:

0:004> !name2ee SpotTheDefect1!SpotTheDefect1.Program
Module:      000007fa66f82f80
Assembly:    SpotTheDefect1.exe
Token:       0000000002000002
MethodTable: 000007fa66f838a8
EEClass:     000007fa67092240
Name:        SpotTheDefect1.Program

Once we’ve gotten the address to the method table, we can then dump that out specifying the ‘-md’ option to get the addresses of the methods in that class:

0:004> !dumpmt -md 000007fa66f838a8
EEClass:         000007fa67092240
Module:          000007fa66f82f80
Name:            SpotTheDefect1.Program
mdToken:         0000000002000002
File:            C:\Users\Daniel\Documents\Visual Studio 11\Projects\SpotTheDefect1\SpotTheDefect1\bin\Debug\SpotTheDefect1.exe
BaseSize:        0×18
ComponentSize:   0×0
Slots in VTable: 9
Number of IFaces in IFaceMap: 0
————————————–
MethodDesc Table
           Entry       MethodDesc    JIT Name
000007fac557a7c0 000007fac52037a0 PreJIT System.Object.ToString()
000007fac5624cb0 000007fac52037a8 PreJIT System.Object.Equals(System.Object)
000007fac56247a0 000007fac52037d0 PreJIT System.Object.GetHashCode()
000007fac5587420 000007fac52037e8 PreJIT System.Object.Finalize()
000007fa670a0090 000007fa66f838a0    JIT SpotTheDefect1.Program..cctor()
000007fa66f8c038 000007fa66f83898   NONE SpotTheDefect1.Program..ctor()
000007fa670a00e0 000007fa66f83868    JIT SpotTheDefect1.Program.Main(System.String[])
000007fa670a0270 000007fa66f83878    JIT SpotTheDefect1.Program.Thread1()
000007fa66f8c030 000007fa66f83888   NONE SpotTheDefect1.Program.Thread2()

You will notice that the methods are marked wither “JIT”, “PreJIT” or “NONE” – this indicates if the JIT has compiled the method (“JIT”), if NGEN compiled the method ahead of time (“PreJIT”) or if the method is yet to be compiled (“NONE”). I’m interested in Thread1, which has been compiled by the JIT, so now I can dump out the method descriptor (I’ll also show later on what happens if you try to get a method that is yet to be compiled).

0:004> !dumpmd 000007fa66f83878   
Method Name:  SpotTheDefect1.Program.Thread1()
Class:        000007fa67092240
MethodTable:  000007fa66f838a8
mdToken:      0000000006000002
Module:       000007fa66f82f80
IsJitted:     yes
CodeAddr:     000007fa670a0270
Transparency: Critical

From here I now know the method descriptor and the address of the code, so I can dump the IL (using the method descriptor) and the actual assembly (using the code address)

0:004> !dumpil 000007fa66f83878   
ilAddr = 00000000009e20a0
IL_0000: nop
IL_0001: ldsfld SpotTheDefect1.Program::_disposed
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: brtrue.s IL_0017
IL_000a: nop
IL_000b: ldsfld SpotTheDefect1.Program::_foo
IL_0010: callvirt Foo::Bar
IL_0015: nop
IL_0016: nop
IL_0017: ret

0:004> !U 000007fa670a0270
Normal JIT generated code
SpotTheDefect1.Program.Thread1()
Begin 000007fa670a0270, size 61

c:\Users\Daniel\Documents\Visual Studio 11\Projects\SpotTheDefect1\SpotTheDefect1\Program.cs @ 24:
>>> 000007fa`670a0270 4883ec38        sub     rsp,38h
000007fa`670a0274 c644242000      mov     byte ptr [rsp+20h],0
000007fa`670a0279 48b83034f866fa070000 mov rax,7FA66F83430h
000007fa`670a0283 8b00            mov     eax,dword ptr [rax]
000007fa`670a0285 85c0            test    eax,eax
000007fa`670a0287 7405            je      SpotTheDefect1!SpotTheDefect1.Program.Thread1()+0x1e (000007fa`670a028e)
000007fa`670a0289 e8c6cda45f      call    clr!TranslateSecurityAttributes+0x62a9c (000007fa`c6aed054) (JitHelp: CORINFO_HELP_DBG_IS_JUST_MY_CODE)
000007fa`670a028e 90              nop

c:\Users\Daniel\Documents\Visual Studio 11\Projects\SpotTheDefect1\SpotTheDefect1\Program.cs @ 25:
000007fa`670a028f 8a059e33eeff    mov     al,byte ptr [000007fa`66f83633]
000007fa`670a0295 88442420        mov     byte ptr [rsp+20h],al

c:\Users\Daniel\Documents\Visual Studio 11\Projects\SpotTheDefect1\SpotTheDefect1\Program.cs @ 26:
000007fa`670a0299 0fb6442420      movzx   eax,byte ptr [rsp+20h]
000007fa`670a029e 85c0            test    eax,eax
000007fa`670a02a0 7527            jne     SpotTheDefect1!SpotTheDefect1.Program.Thread1()+0×59 (000007fa`670a02c9)
000007fa`670a02a2 90              nop

c:\Users\Daniel\Documents\Visual Studio 11\Projects\SpotTheDefect1\SpotTheDefect1\Program.cs @ 27:
000007fa`670a02a3 48b83856e21200000000 mov rax,12E25638h
000007fa`670a02ad 488b00          mov     rax,qword ptr [rax]
000007fa`670a02b0 4889442428      mov     qword ptr [rsp+28h],rax
000007fa`670a02b5 488b442428      mov     rax,qword ptr [rsp+28h]
000007fa`670a02ba 803800          cmp     byte ptr [rax],0
000007fa`670a02bd 488b4c2428      mov     rcx,qword ptr [rsp+28h]
000007fa`670a02c2 e8b1bdeeff      call    SpotTheDefect1.Program+Foo.Bar() (000007fa`66f8c078) (SpotTheDefect1.Program+Foo.Bar(), mdToken: 0000000006000006)
000007fa`670a02c7 90              nop

c:\Users\Daniel\Documents\Visual Studio 11\Projects\SpotTheDefect1\SpotTheDefect1\Program.cs @ 28:
000007fa`670a02c8 90              nop

c:\Users\Daniel\Documents\Visual Studio 11\Projects\SpotTheDefect1\SpotTheDefect1\Program.cs @ 29:
000007fa`670a02c9 eb00            jmp     SpotTheDefect1!SpotTheDefect1.Program.Thread1()+0x5b (000007fa`670a02cb)
000007fa`670a02cb 90              nop
000007fa`670a02cc 4883c438        add     rsp,38h
000007fa`670a02d0 c3              ret

A couple of things to note: Firstly, the IL tends to match up with the actual code quite accurately (unless you are using compiler magic like yield return or await/async), and I’m using !U to dump the disassembly which (if you have the symbols) will show you what line of code generated which assembly commands (although the JIT may rearrange sections of code (especially for try/catch/finally statements) – so don’t expect the assembly to always work out as nicely as it did above). You may have also noticed that the assembly is quite verbose, contains debugging information (“CORINFO_HELP_DBG_IS_JUST_MY_CODE”) and some unnecessary NOPs (e.g. line 28 of my code was turned into a single NOP) – this is because I was using a debug build of SpotTheDefect1.exe, if I was using the release build, then a lot of these instructions would be optimized away (or not generated in the first place).

Finally, if we were interested in the assembly for Thread2, we could try to dump of the method descriptor

0:004> !dumpmd 000007fa66f83888  
Method Name:  SpotTheDefect1.Program.Thread2()
Class:        000007fa67092240
MethodTable:  000007fa66f838a8
mdToken:      0000000006000003
Module:       000007fa66f82f80
IsJitted:     no
CodeAddr:     ffffffffffffffff
Transparency: Critical

But the code address points to nowhere – which is because it hasn’t been compiled yet, so there is no assembly associated with the method (although you could still dump out the IL).

SpotTheDefect[0].Answer[1]

A couple of weeks ago I asked you to play a little game of “Spot the Defect”, and recently I posted the first of three posts with the answers, which focused on the output of the program, what the bug was and a possible way to fix it. This first fix focused on using locks to serialize access and, while locks in .Net are very fast, they are not free and prevent your application from taking full advantage of multi-core hardware. So now we are going to explore a lock free, safe alternative – but first we need to take a step back and remember how objects work in .Net (and most other Object Orientated runtimes)

Can you give me some pointers?

Usually when we code in an object orientated language and we “new up” an object we have a mental model that says that our variable contains the actual object. Similarly, if we then set that object to null, then we believe that we are removing the object from existence – but this is not the case. The variable we assigned the object to does not contain the actual object, but rather it holds a pointer to the actual object in the heap, and so setting that variable to null merely means that we are clearing the pointer, but the object will still reside in the heap until the Garbage Collector (GC) comes along to remove it. Additionally, all we need to do to ward off the GC from destroying an object is to maintain a reference (i.e. a pointer) to it.

Copy, check, continue

(There is probably already a name for this “pattern”, but I couldn’t really find it – so this will have to do. If you have a better name, or find the real name, let me know.)

So, to avoid taking locks, there are a few things that we need to do: firstly, we need to create out own reference to the object that _foo is pointing to such that we don’t have to rely on using _foo (which could become null at any time) and to prevent the GC from eating the object. The easiest way to do this is to make a copy of _foo (remember, that is copying the pointer, not the object). Which leads to my second point: once we’ve made the copy of _foo, we need to check that our copy isn’t null (because _foo has already been set to null). Finally, if our copy isn’t null, then we can continue to do whatever we planned to do.

A couple of notes about the code (you may want to come back to these after reading the code)

• I’m using the var keyword (because I don’t really care what type _foo is, it makes maintenance easier and I’m lazy…)
• We didn’t have to modify Thread2 at all
• The performance overhead to Thread1 is minimal (we allocate a pointer on the stack, copy a pointer to it and then check if it is 0 – in reality the compiler will probably optimize fooLocal away and just use a register, further reducing the overhead)
• If you were really concerned about performance, you could now drop the _disposed variable as well (since it’s not really need it)

And, finally, our updated code:

using System;
using System.Threading;

namespace SpotTheDefect1
{
    class Program
    {
        private static int _x = 0;
        private static Foo _foo = new Foo();
        private static bool _disposed = false;

        static void Main(string[] args)
        {
            Thread thread1 = new Thread(Thread1);
            Thread thread2 = new Thread(Thread2);

            thread1.Start();
            thread2.Start();

            thread1.Join();
            thread2.Join();
        }

        private static void Thread1()
        {
            if (!_disposed)
            {
                var fooLocal = _foo;
                if (fooLocal != null)
                {
                    fooLocal.Bar();
                }
            }
        }

        private static void Thread2()
        {
            Console.WriteLine("Disposing");
            _disposed = true;
            _foo = null;
        }

        private class Foo
        {
            public void Bar()
            {
                Console.WriteLine("Hello, World!");
            }
        }
    }
}

SpotTheDefect[0].Answer[0]

Last week(ish) I posted a quick “Spot the Defect” game, where I asked you to:

• Figure out what it would output
• Find the bug(s)
• Correct the bugs

So today is one of three posts with the answers – I’ll focus on the output, the bug and a trivial correction, with the next two posts diving deeper into other possible solutions.

Explosions, and not the good kind

So, most of you probably ran the code and got the output:

Hello, World!
Disposing

If you were lucky, or had a few things running in the background, you may also have seen:

Disposing

But, it was also possible to get:

Disposing
Hello, World!

Or, even a NullReferenceException!

How is this possible? Because of a very subtle race condition…

Scheduling Conflict

Most of the time, the application would have kicked off both threads, and these threads would run in their entirety without ever being preempted. Additionally, since we started Thread1 before Thread2, in all likelihood Windows would have scheduled and ran the threads in that order. However, it is entirely possible that Windows could decide to preempt either thread at any stage in our code, or execute them in any order. So, in order to see “Disposing” before “Hello, World!” we would need Thread2 to go first and then be preempted just after it wrote to the console to allow Thread1 to run in its entirety. The NullReferenceException is the opposite: If Thread1 is preempted just after it checks _disposed and enters its if-statement, then this allows Thread2 to “race in” and set _foo to null, causing Thread1 to hit a NullReferenceException when it resumes.

This kind of bug is especially difficult to diagnose because of how “tight” the timing is. You would see the exception intermittently at best (you can try this by wrapping it in a for-loop), and it would occur even less frequently if there was a debugger attached or if you added more diagnostics\tracing (simply because there becomes more “safe” lines of code to be preempted at, so the timing window becomes even tighter). And even if, somehow, you did manage to get a crash dump with the exception, you would need to dig through all of your code to try to find how you ended up crashing (which, if you’re not thinking about how threads can affect each other, is about as effective as bashing your head against a wall).

When in doubt, lock

At the beginning of this post, I described this as the “trivial” solution, but that doesn’t mean that you should discredit it – although locks seem like the most heavy handed approach, they are usually the safest as well. For those of you unfamiliar with C#’s lock keyword (or the Monitor Enter\Exit that it wraps), this is a language construct that acts similar to a critical section or a mutex, except that you do not create a synchronization primitive to manage the state of the lock, but rather you lock on an object (and the Monitor maintains the lock state). Take a minute to think about that: you must lock on an object – not a primitive, not a struct, and not null. This complicates matters for our code, since the only object we have is _foo, and we can’t guarantee that it isn’t null. We also can’t lock on the ‘this’ object because we are in a static method (not that you should ever lock on ‘this’ or any other object that is publically visible, as this can lead to unexpected deadlocks if other code decides to lock on your object or its properties\return values). The common solution to this problem is to add a dedicated ‘lock object’ that is only ever used for locking and is guaranteed to not be null.

Many developers shy away from locks as they are viewed as performance issues and the leading cause of hangs. While a lock is not free, you’d be surprised just how fast a lock is, especially when there is no contention on it. Deadlocks, however, always remain a problem – but, I can say from experience: it is much easier to reason about the ordering that locks are taken and released, than to consider and find the type of bug I’ve described above.

So, this “trivial” solution is to add a new “lock object”, and then to serialize access to _foo:

using System;
using System.Threading;

namespace SpotTheDefect1
{
    class Program
    {
        private static int _x = 0;
        private static Foo _foo = new Foo();
        private static bool _disposed = false;
        private static object _fooLockObject = new object();

        static void Main(string[] args)
        {
            Thread thread1 = new Thread(Thread1);
            Thread thread2 = new Thread(Thread2);

            thread1.Start();
            thread2.Start();

            thread1.Join();
            thread2.Join();
        }

        private static void Thread1()
        {
            if (!_disposed)
            {
                lock (_fooLockObject)
                {
                    if (_foo != null)
                    {
                        _foo.Bar();
                    }
                }
            }
        }

        private static void Thread2()
        {
            Console.WriteLine("Disposing");
            _disposed = true;
            lock (_fooLockObject)
            {
                _foo = null;
            }
        }

        private class Foo
        {
            public void Bar()
            {
                Console.WriteLine("Hello, World!");
            }
        }
    }
}

SpotTheDefect[0]

Let’s play a little game of “Spot the Defect”. For the following code, see if you can:

• Figure out what it would output
• Find the bug(s)
• Correct the bugs

(And I’ll do a post next week with the answer)

using System;
using System.Threading;

namespace SpotTheDefect1
{
    class Program
    {
        private static int _x = 0;
        private static Foo _foo = new Foo();
        private static bool _disposed = false;

        static void Main(string[] args)
        {
            Thread thread1 = new Thread(Thread1);
            Thread thread2 = new Thread(Thread2);

            thread1.Start();
            thread2.Start();

            thread1.Join();
            thread2.Join();
        }

        private static void Thread1()
        {
            if (!_disposed)
            {
                _foo.Bar();
            }
        }

        private static void Thread2()
        {
            Console.WriteLine("Disposing");
            _disposed = true;
            _foo = null;
        }

        private class Foo
        {
            public void Bar()
            {
                Console.WriteLine("Hello, World!");
            }
        }
    }
}

Collectively Concurrent

“The concept of a stack in programming is very similar to a stack of plates in real life, except that you can cheat a little – for instance, if you’re willing to accept that plates can float, then you can ignore gravity.”

One of the fantastic things about using a rich framework like .Net is that many of the basic data structures that programmers require already exists in a efficient and easy to use form. We also make sure to update these pre-built data structures with the new features that we introduce in the language, for instance in .Net 2.0 we introduced generics, and so the System.Collections.Generic namespace was created. With.Net 4.5 we are introducing new async APIs and the async\await keyword pair, meaning that programmers will now need to deal with concurrency and multithreading more often especially if their application has any shared data structures. Luckily enough, we already have the appropriate APIs that were introduced in 4.0: the System.Collections.Concurrent namespace.

Stack it. Queue it. Bag it.

The first couple of APIs I’d like to introduce you to is the ConcurrentStack and ConcurrentQueue. These are exactly as they sound: A stack and a queue that permit concurrent operations. One common trap when writing a multithreaded application is the pattern of checking the Count of the collection to see if an item is available, before attempting to take an item – which is fine with single threading, but in a multithreaded environment it is possible to have another thread jump in between your check and getting the item which then takes the last item before you can. Instead, the concurrent collections have the the TryPop and TryDequeue methods, which will atomically check the size of the structure and return an item to you if there is one available.

The other data structure I hinted at is the ConcurrentBag. Unlike the Stack or Queue, the ConcurrentBag has no guarantees about the order of output versus input – it’s an “Any In, Any Out” collection. This allows ConcurrentBag can have a much more efficient implementation when there is contention, since the collection can return any object that it currently holds, rather than having to coordinate with any of the threads accessing it in order to return objects in the correct order. One of the best uses of a ConcurrentBag is for a non-time sensitive resource cache, like a buffer pool – where you want to have the best performance even with contention, but it is ok to not return the most recently used object (as you would want to do with a connection pool).

Performance

One of the issues with writing multithreaded applications is attempting to measure performance, especially when you have a shared resource. If you are running a single threaded test with the above data structures, then you may notice that simply putting a standard Stack or Queue inside of a lock gives better performance than the Concurrent equivalent. However, introduce some contention (i.e. have multiple threads attempting to access the same object), and the Concurrent structures begin to shine. Additionally, you need to be careful when doing multithreaded micro-benchmarks as you may introduce too much contention (since a “real” application is likely to do some work with the object is just obtained, rather than handing it back to the collection).that would then skew your results.

However, unless you have a high-performance single threaded application or a multithreaded application with no shared resources, then a concurrent collection will be your best bet. It may be slower in an application with little load, but it will be much easier to scale it to a larger application if needed.

Thread safety

One of our focuses for .Net 4.5 was on async and improving support for doing ADO.NET asynchronously. A side effect of this is that we did a lot of work improving our thread-safety story. With .Net 4.0 and prior, we simply had a blanket statement that multithreaded access to any ADO.NET object was not supported, except for cancellation (i.e. SqlCommand.Cancel). Even then, there were some unusual corner cases with cancellation that resulted in unexpected circumstances. With 4.5 we could have maintained this stance, but we realized that the use of async makes mistakes with accessing objects on multiple threads much more likely (e.g. when manually calling ContinueWith or if you forget the ‘await’ keyword).

Pending Operations

With the .Net 4.5 Developer Preview, if you try to call any operation on an ADO.NET object while it has an asynchronous operation pending (including the old Begin\End methods), then we throw an InvalidOperationException. While this isn’t the nicest of behaviors, it is much better than the 4.0 and below behavior (which was undefined, although typically resulted in NullReferenceExceptions and data corruption). The reason that we opted for an exception instead of doing something ‘smarter’ (like waiting for the operation to complete), is that a secondary call to an object is typically a coding mistake (e.g. forgetting the ‘await’ keyword) and that anyone who needs to do multiple operations should schedule the second operation via await or ContinueWith.

However, if there is a synchronous operation in progress, we still do not support starting another operation on that object. And, by ‘not supported’, I mean that we have no checks in place and no guarantees on the behavior. Unfortunately, there is no easy way to detect multi-threaded access to an object (even from within a debugger), so you need to make sure that your code is correct. The simplest way to do this is by never sharing an ADO,NET object between multiple threads. This means that if you have a shared ‘Data Access Layer’ in your application, you should be opening a new connection per call (and closing it afterwards) or, if you have something like a singleton logger, you may want to consider a Consumer\Producer pattern such that there is only one thread performing the logging.

Cancellation

As I mentioned previously, cancellation is the only operation that we have always supported from another thread. In .Net 4.5 we have done a lot of work to ensure that cancellation is still supported, and we have also dealt with quite a few of the corner cases. For instance, any time there is a fatal error on a connection (e.g. the network has gone down) then we close the current connection. While this may seem reasonable, it means that cancelling an operation could result in the connection being closed while another operation (i.e. the one being cancelled) was running. While we haven’t changed this behavior in .Net 4.5, we have made sure that any other operation can handle the connection be closed due to an error, even if it means throwing an InvalidOperationException.

Multi-threaded MARS

In SQL Server 2005, we introduced a feature called "Multiple Active Result Sets", or MARS, which allowed multiple commands to be executed on a single connection. In .Net 4.0 and prior this had the caveat that you could not execute multiple commands or use multiple readers simultaneously, which greatly limits the usefulness of MARS. In .Net 4.5 we have done a lot of work to try to enable this scenario for SqlClient and, although we are not yet officially supporting it, it is something that we would like for people to try out as a part of their testing of the Developer Preview and async. As a side note, there is a performance overhead for enabling MARS, so it may be worth also investigating if you can disable the feature instead.

Issue 14

(Rather than just reiterating the new features in ADO.NET that we announced for //Build/, I figured that I’d do a series of posts covering various features in depth – although this first "feature" shipped a bit earlier than the 4.5 Developer Preview)

What’s in a fix

If you remember last month’s Patch Tuesday, the first Reliability Update for .Net 4.0 was release, including a bug fix for System.Data.dll. However, those of you who read the support article would have been greeted by this cryptic message:

---

Issue 14
Consider the following scenario

• You use the .NET Framework Data Provider for SQL Server (SqlClient) to connect to an instance of Microsoft SQL Azure or of Microsoft SQL Server.
• An established connection is removed from the connection pool.
• The first request is sent to the server.

In this scenario, an instance of SqlException is encountered, and you receive the following error message:
A transport-level error has occurred when sending the request to the server.

---

So given that description, can you tell what the original bug was, or what we fixed?
No? Neither can I – and I wrote the fix…

Historical Perspective

To explain "Issue 14", we’ve first got to look back at the history of ADO.NET, back to the 2.0 (or, possibly, 1.0) days. In the original design of the Connection Pool it was decided that, if there was a catastrophic failure of a connection, then the entire pool should be cleared. This was a reasonable assumption, since being unable to communicate with the server typically means that either the server is down (or restarted), the client network connection has died or failover has occurred – in any of these circumstances, it is unlikely that any other connection in the pool had survived.

Fast forward to today, and some of the original assumptions of the connection pool are no longer valid. Due to the increased popularity of cloud computing and connected devices, connections to SQL Servers are might not be going over ultra-fast and ultra-reliable links inside a data center. Instead, they may be going over the internet, which means that they are unreliable and could drop at any time. This, combined with SQL Azure’s policy of dropping connections that have been idle for over 30 minutes, meant that we could have one dead connection in the pool, but the rest would be ok.

Check Connections

So now we’re connecting over unreliable connections and still clearing the pool when it’s possible that only one of the connection had died. On top of that, we don’t know the connection is dead until someone tries to execute a command on the connection (and then gets an error, despite the fact that they had just opened the connection). So what to do?

Firstly, we are now checking the state of the connection when we remove it from the connection pool and, if its dead, giving you a new connection. This greatly decreases the likelihood that you will be trying to execute on a bad connection (although its still possible, as we are relying on Windows to know about the state of the underlying TCP connection, and since there is a race condition between us checking and you executing on the connection).

Secondly, we no longer clear the pool when there is a fatal error on a connection – so we’re no longer dropping (hopefully) good connections just because one connection is bad. Conversely, since we are checking connections before using them, we are still responsive to events like failover or network disconnects.

Best Practices

If you read the last section carefully, you would have noticed one of the caveats of this feature: "there is a race condition between us checking and you executing on the connection", which leads to my first recommendation:

Follow the Open-Execute-Close pattern

Every time you need to interact with SQL Server, you should open a fresh connection, execute your command (and deal with the data reader if you open one) and then close the connection (since SqlConnection, SqlCommand and SqlDataReader are all implement IDisposable, the best way to do this is with a ‘using’ statement). If you need to expose the data reader to a higher level API, and don’t want to cache the data in the data reader, then you should wrap the connection, command and reader inside a new class that implements IDisposable and return that instead.

My second recommendation relates back to my previous post on connection strings:

Use our connection pool

Despite the connection pooling code being rather old, it is extremely fast, reliable and it works. Opening connections from the pool and returning them afterwards is incredibly quick, especially when compared to opening a fresh connection or executing a command on a connection. Additionally we have the ability to introduce features like this which custom pooling code can’t.

Finally, this improvement is no replacement for proper retry code.

Improvements in 4.5

In the .Net 4.5 Developer Preview, we’ve made this feature more scalable, especially for high-throughput application servers where connections do not sit idle in the pool for very long.

As a final note, if you haven’t already upgraded to .Net 4.5, then you should make sure that you’ve installed the 4.0 Reliability Update.

Connection Strings: The smaller, the better

Today I’d like to talk about the wonderful and magic things that are Connection Strings. If you’re not familiar with connection strings, they are the way that a developer informs ADO.NET which server to connect to and connection options to use.

A Simple Rule

The problem with connection strings (actually, there are quite a few problems, but I’ll stick to the point of this post) is that there are far too many options to choose from, but let me simplify everything for you:

If you don’t need to change an option, or don’t know what it does, then don’t specify it.

Default Values

The default values for connection string options are there for a reason, so unless your application has some unusual requirements, you should stick to the default values. However, you shouldn’t re-specify the default values in your connection string either, unless you heavily rely on the behavior provided by that default value. The reason for this is that we may change the default at a later date if we make code changes (which make a different value more optimal), or we introduce a new value that is better for most developers. The most common case I see here is setting the "Max Pool Size" value – for the vast majority of applications the default size of 100 is reasonable, however you shouldn’t specify 100 in case we (or SQL Server) make modifications to our network code and so are able to increase the maximum, or perhaps we’d have different values for client and server applications*. Either way, you’d want to be able to get this benefit for ‘free’ by not specifying a value, rather than having to modify all of your deployed config files with the new values (because, of course, you are using config files, and don’t have the connection string hard-coded in your application).

Optional Extras

Alternatively. the thought "I don’t know what it does, but I might use it later" may also lead to included unneeded connection string options. If there was some beneficial feature that didn’t have any negative side effects, then we would enabled that option be default. The fact that a connection string options is disabled by default should indicate that there is some other side effect of turning it on (typically a performance hit, but possibly other things). If you don’t know what an option does, then you probably aren’t taking advantage of it, and if you aren’t taking advantage of it, then you don’t need it. A good example of this is "Multiple Active Result Sets" (aka MARS). This is a feature introduced in SQL Server 2005 that permits multiple commands to be executed on a single connection simultaneously**. This may sound great, but most applications don’t really have a need for it, they can simply open another connection. However, if you turn it on because you "may need it", then you will be taking a performance hit and possibly hiding errors in your code (since having MARS off ensures that you dispose a SqlDataReader before trying to open a new one on the same connection).

Final Caveat

Before you go ahead and start removing options from your connection strings, there is one thing you should be aware of: since you had these options specified, there may be parts of your code that rely on the non-standard behavior. For instance, if you turn off MARS, any part of your code that created multiple readers on the same connection will start throwing exceptions, or reducing the Max Pool Size may reveal a connection leak that was previously hidden (resulting in more exceptions in your code). So be very careful when changing connection string options and ensure that you run all of your tests (which, of course, you have) and have a rollback strategy to deploy the old connection string if something goes wrong.

---

*These are just examples and are not necessarily in our current plans. But if you like these ideas, or have some of your own, feel free to post the on Connect
**Technically speaking, we don’t support multithreaded access to the same connection, even with MARS turned on (unless you are cancelling a Command). So, you would still need to synchronize each of the Command\Reader executions\reads on the same connection.