At the PDC I showed a demo of the new parallel stacks window in Visual Studio 2010 and how task view and method view can make navigating a multi-threaded program in the debugger more intuitive when compared to the existing threads and stacks windows (thought these got better too).  I thought I’d take a moment and share the key points and the code I used for this.

The code is a simple deadlock of 5 tasks waiting on an event that is never set.  I don’t expect that you’ll be able to read the text on many of these pictures, but I believe the point will still clear (and you can always try this in VS 2010 yourself.

Call Stack & Thread Windows

This is the way that we’ve been debugging multi-threaded programs via the Call Stack & Thread windows.  If you’ve been here before it can be difficult if you have more than one thread to orient on and find your location. It’s often a matter of poking through each thread in the Threads window and checking the Call Stack window.

This is one of the reasons why in VS2010 you can now expand the Call Stack inline and search in the Threads window.  The inline expansion looking on and search actually can help significantly if you know what you’re looking for in a particular deep stack, but for this particular issue it’s not the most efficient way of seeing what’s going on…

image

The Parallel Stacks Window

The Parallel Stacks Window shows you all the stacks for all the threads at once. To help with the immense amounts of screen real estate required for this, it trims the fully qualified callstack name (you can still see it in a tooltip) and it also groups the related stacks so you can start seeing any relationships and in this case hopefully seeing why this app is deadlocked.

image 

The Parallel Stacks Window: task view

Since this is an application build on tasks, we can set the filter to show only the running tasks and now the picture starts getting more clear (and the text is almost readable).   This is because the tasks view filters out the runtime portions of the callstack and only shows the stack frames that are part of the task.  You can see that we have 4 tasks running and it looks like they are waiting in event::wait.

image

The Parallel Stacks Window: method view

Switching the focus to event::wait and toggling ‘method view’ which will only show callers and callees in a particular method makes this incredibly obvious.

image

So here’s the code:

This was implemented with template recursion (thanks go to twoscomplement who’s colossal cave inspired tweet: “You are in a maze of twisty template overloads, all alike” inspired the particular code example.

#include <memory>
#include <ppl.h>
#include <iostream>
using namespace ::std;
using namespace ::Concurrency;
event e;

template <int N>
void youre_in_a_maze()
{
    printf(“%dth task\n”,N);
    e.wait();
}

template <int N>
void of_template_overloads()
{
    youre_in_a_maze<N>();
};

template <int N>
void all_alike()
{
    of_template_overloads<N>();
};

template <int N>
struct colossal_task
{
    shared_ptr<colossal_task<N – 1>> task;
    task_group& m_tasks;
    colossal_task(task_group& tasks):m_tasks(tasks),task(new colossal_task<N – 1> (tasks))
    {
        m_tasks.run(*task);
    }
    void operator ()() const
    {
        all_alike<N>();
    }
};

template <>
struct colossal_task <0>
{
    task_group& m_tasks;
    colossal_task(task_group& tasks):m_tasks(tasks)
    {
    }
    void operator ()() const
    {
        printf(“0th task\n”);
    }
};

int main()
{
    task_group tasks;
    colossal_task<5> t(tasks);
    tasks.wait();
    return 0;
}

Advertisements