Did you know that Visual Studio shows deadlocked tasks?

No comments

Wednesday, December 30, 2015

I didn’t…
And it’s not a new feature – since it existed since freaking Visual Studio 2010!
Yesterday during an unrelated meeting Alon Fliess showed a bunch of us developers how Visual Studio detects deadlocks in tasks (automatically) and shows the current task status in both Parallel Tasks and Tasks debug windows (duh).
I got home late but I wanted to experiment and see what would happen and so I wrote a simple program to see how well Visual Studio understands the bugs I can trough at it:
static void Main(string[] args) 
{ 
    int taskCount = 6; 
    var tasks = new Task[taskCount]; 
    var autoResetEvent = new AutoResetEvent(false); 
    for (int i = 0; i < taskCount; i++) 
    { 
        tasks[i] = Task.Factory.StartNew(state => 
        { 
            var index = (int)state; 
            if (index < 3) 
            { 
                tasks[(index + 1) % 3].Wait(); 
            } 
            else if (index == 3) 
            { 
                Task.Factory.StartNew(() => 
                { 
                    while (true) { } 
                }).Wait(); 
            } 
            else 
            { 
                autoResetEvent.WaitOne(); 
            } 
        }, i); 
    } 

    Task.WaitAll(tasks); 

    autoResetEvent.Set(); 
}
What a mess – I have three tasks waiting on each other (deadlocked), two more tasks waiting indefinitely on a AutoResetEvent and one task that starts yet another task that runs an infinite loop (just for fun).
After a few seconds I paused/breaked execution and got the following (Debug –> windows –> Tasks):
image
So out of the 6 tasks I spawned the first three deadlocks are detected by VS, Three tasks that show as blocked (waiting for AutoResetEvent and waiting for another task to complete). The only task that shows as running is the one that happily burning CPU on a while loop that would never end (also known as the Halting problem).
That’s good enough for me.
I guess it’s another case of a useful feature that I always wanted but didn’t know already existed.

Happy coding…

VS2015 Update 1 brings (back) parallel test execution

2 comments

Friday, December 04, 2015

Yesterday I’ve installed the new VS2015 update and tried to make my machine talk to my win10 (IoT core) Raspberry PI. It didn’t help but that’s a story for another blog post – spoiler: it was a problem with my laptops Ethernet port.

After the dust settled I’ve started reading about the new goodness that was just added to my trusty Visual Studio and found out that Microsoft has decided to give us the parallel test execution.

It all started back in the long forgotten Visual Studio 2010. Back then we had a great feature called parallel test execution. It did exactly that – reduce run speed by utilizing several cores to run tests – it was well hidden but for those of use who know where to enable it – it worked like a charm - as long as other tools, especially your Mocking framework of choice supported multi threading.

Then came VS2012 and the ability to run unit tests side by side disappeared… you could use it but for the price of using the old soon to be legacy test runner.

Since I liked the fact that my test run took less time I was happy to see that the feature I liked came back.

Enabling parallel tests is simple – first create a new test.runsetings – don’t look for a template (because there is none), just add a new xml file and rename it.

For parallel tests you just need the file to contain the following lines:


<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<RunConfiguration>
<MaxCpuCount>0</MaxCpuCount>
</RunConfiguration>
</RunSettings>

For the value of MaxCpuCount  use the number of threads you want to use (usually 1 for sequential run), or instead ‘0’ or a number greater of the number of your machine logical core (please use ‘0’).

Look under Test menu for “Select Test Settings File” and choose the newly minted (test settings) file.

image

For more information of what the test settings file can do for you – read this MSDN page.

Now when running the tests you’ll see improvement it the time it takes for them to finish.

mstest_parallelUntitled

I did notice that it took longer for the tests to start running and there’s a barely noticeable delay at the end of the run but other than that – parallel tests!

As you can see the runner runs assemblies in parallel so if you have a lot of tests in one assembly – you might not benefit from this feature, please consider splitting your tests (and probably production code as well).

I still need to check if (and which) mocking frameworks would work with this new(ish) test execution.

 

Happy coding…

Related Posts Plugin for WordPress, Blogger...