Socialize Part 3

31.05.2010 um 8:26 am · Abgelegt unter Internet Resources

Kommentare abgeschalten

Lesser-known Multi-threaded Debugging Support in Visual Studio 2010

25.05.2010 um 6:56 pm · Abgelegt unter .NET Help

We’ve been very excited about the new debugging windows in Visual Studio 2010, namely Parallel Tasks and Parallel Stacks, as well as the newly revamped Threads window, and thus we’ve talked about them quite a bit. For an overview, you can read the MSDN Magazine article at http://msdn.microsoft.com/en-us/magazine/ee410778.aspx, and Daniel Moth has a larger collection of related materials in his blog post on Parallel Debugging. From all the coverage these windows have been getting, however, it would be easy to overlook many of the other niceties that have been added to Visual Studio 2010 around multithreaded debugging, and in particular related to the new parallelism support in .NET 4. With this post, I hope to bring some of those lesser-known but still quite useful features to light.

DebuggerDisplayAttribute

Wherever applicable, our new .NET 4 parallelism-related types sport DebuggerDisplay attributes in order to make it really easy to see important details about the relevant component at a glance . This, of course, exists for collections as you would expect, e.g.

However, it also works for other types. For example, if you hover over an instance of Task, you’ll see details like the Task’s action or function, its execution status, etc.:

The following parallelism-related types new to System, System.Threading, System.Threading.Tasks, and System.Collections.Concurrent in .NET 4 all have DebuggerDisplayAttribute applied to them to showcase useful data:

• AggregateException
• Barrier
• BlockingCollection<T>
• CancellationToken
• ConcurrentBag<T>
• ConcurrentDictionary<TKey,TValue>
• ConcurrentQueue<T>
• ConcurrentStack<T>
• CountdownEvent
• Lazy<T>
• ManualResetEventSlim
• ParallelLoopState
• SemaphoreSlim
• SpinLock
• Task
• Task<TResult>
• TaskScheduler
• ThreadLocal<T>

DebuggerTypeProxyAttribute

Similarly, wherever applicable, our new .NET 4 parallelism-related types utilize debugger type proxies in order to provide a concise and useful debugging view of the state of an instance. For example, the TaskScheduler type (which represents the scheduling infrastructure used to execute tasks) provides a type proxy that allows you to see all of the tasks that have been scheduled to that scheduler instance and are awaiting execution, e.g.

Task itself also has a debugger type proxy, so you could further expand one of these tasks to understand more details, or just view an individual task you might have a reference to, e.g.:

There are some cool tricks you can play with this as well.  For example, the Task type internally maintains information about what the current Task is; while this information isn’t exposed publicly, and while it could change in the future, for .NET 4 you can access this information through the debugger by accessing Task’s static InternalCurrent property, allowing you to learn about the current task executing:

Here’s a list of the new parallelism-related types that have a DebuggerTypeProxy attribute applied:

• BlockingCollection<T>
• ConcurrentBag<T>
• ConcurrentDictionary<TKey,TValue>
• ConcurrentQueue<T>
• ConcurrentStack<T>
• Lazy<T>
• SpinLock
• Task
• Task<TResult>
• TaskScheduler
• ThreadLocal<T>

IntelliTrace Events

IntelliTrace is an extremely cool new feature of Visual Studio 2010, one you can learn more about in the MSDN Magazine article at http://msdn.microsoft.com/en-us/magazine/ee336126.aspx. Built-in to Visual Studio 2010 are several events specific to parallelism and/or that relate to some of these new .NET 4 types. You can see these events in the debugging options for IntelliTrace:

These events are not enabled by default, so if you want them to be tracked, you’ll need to enable them in the above options dialog, available through “Debugging | Options and Settings… | IntelliTrace | IntelliTrace Events”.

With these events selected, you’ll see the relevant events show up in the IntelliTrace events window:

Thread Slipping

When stopped at breakpoints, the debugger is able to use technology called “funcevals” to execute code in order to compute results, such as to show you data in windows like Watch and Locals, in tooltips, and so forth. Of course, this funceval is able to execute any arbitrary .NET code, including code that might take locks. When stopped at a breakpoint, the debugger has frozen all of the application’s threads, and then to run a funceval, it wakes up one thread and uses it to run the target function. If this function depends on another thread doing some work in order for the unfrozen thread to make forward progress, the system will deadlock, as the thread that needs to do the work is unable to do so.

The Visual Studio 2010 debugger introduces the concept of “thread slipping,” which the new parallelism types in .NET 4 take advantage of in key places. If the debugger is making a funceval into a particular piece of code we know is likely to result in this kind of negative situation, the Framework informs the debugger that it should stop what it’s doing and make sure the user really wants to continue. The user is then presented with an option that allows the debugger to wake up all of the processes’ threads until the target function completes, at which point the debugger will again freeze all of the threads.

We take advantage of this, for example, in Task<T>.Result:

Notice the little threads icon in the Watch window line for t3.Result:

By clicking that button, the debugger will wake up the system until t3.Result completes (or until a really long timeout expires):

This thread slipping functionality is used in several places throughout Parallel Extensions, including Lazy<T>, ThreadLocal<T>, Task<T>, and PLINQ. You can utilize it in your own types as well, by calling System.Diagnostics.Debugger.NotifyOfCrossThreadDependency() prior to the problematic operation.

Kommentare abgeschalten

Why is TaskContinuationsOptions.ExecuteSynchronously opt-in?

24.05.2010 um 7:24 pm · Abgelegt unter .NET Help

For a relatively advanced feature, I’ve been surprised how often this question has come up recently.
 
When a task completes, its continuations become available for execution, and by default, a continuation will be scheduled for execution rather than executed immediately.  This means that the continuation has to be queued to the scheduler and then later retrieved so that it may be run.  Given that there’s some overhead involved there, why would we choose to make that the default behavior rather than avoiding that overhead by executing the continuation synchronously upon completion of the antecedent rather than queueing it? There are a few reasons.
 
First, it’s quite common for multiple continuations to be created off of the same task.  If continuations were executed synchronously by default, we would lose out on a valuable opportunity for parallelism, as they would all be executed synchronously one after the other.  By scheduling the continuations to run asynchronously rather than executing them synchronously, we expose those continuations to be picked up by other available threads, thereby allowing them to run in parallel.
 
Second, it’s quite common for long chains of continuations to be formed, with one task continuing off of another, and another off of that, and another off of that, and so on.  If these continuations were all executed synchronously, the completion logic from one task would invoke the next task, and its completion logic would invoke the next… each of these would lead to additional stack frames piling up on top of each other, and with a long enough chain, we could end up overflowing the stack.
 
Third, a common solution to such overflow conditions as discussed above is to use a ”trampoline,” where you store a reference to some work to be done, back out of your current stack frame(s), and have a higher-level frame (typically a looping construct) look for the stored reference and execute it.  That way, after every invocation, rather than picking up the next piece of work immediately, you store the reference, back out, and then execute it.  This, as it happens, is exactly the solution TPL employs to make asynchronous execution fast.  Remember that as part of .NET 4, the ThreadPool’s internal implementation was augmented with work-stealing queues to which TPL has access.  When work running on a ThreadPool thread schedules a Task for execution, that Task is put into a work-stealing queue local to that thread.  The thread is able to push and pop work items from it very efficiently and with minimal synchronization.  Now, when a task completes, it’s typically completing on a ThreadPool thread, and as such all of the continuations it queues get queued to the local work-stealing queue.  The thread will then go in search of work to do, first checking its local queue, and immediately find one of the continuations it just queued.  This is, in effect, the trampoline.  The thread picks off the most recently queued continuation efficiently and begins processing it.
 
These are the primary reasons why we default to queueing continuations rather than just executing them synchronously: it provides more opportunities to leverage parallelism, it’s the safer choice, and the difference in performance is typically not important.  Of course, microbenchmarks will highlight a non-negligable performance difference, so if you’re dealing with continuations that contain very few instructions, have little risk of blocking, etc., ExecuteSynchronously can be worthwhile.  Consider the following simple test:

using System;

using System.Diagnostics;

using System.Threading.Tasks;

class Program

{

    const int NUM_CONTINUATIONS = 100000;

    static long Test(bool executeSynchronously)

    {

        GC.Collect();

        GC.WaitForPendingFinalizers();

        GC.Collect();

        var first = new Task(() => { });

        var last = first;

        for (int i = 0; i < NUM_CONTINUATIONS; i++)

        {

            last = last.ContinueWith(delegate { }, executeSynchronously ?

                TaskContinuationOptions.ExecuteSynchronously :

                TaskContinuationOptions.None);

        }

        var sw = Stopwatch.StartNew();

        first.Start();

        last.Wait();

        return sw.ElapsedMilliseconds;

    }

    static void Main(string[] args)

    {

        while (true)

        {

            long withoutExecuteSynchronously = 0, withExecuteSynchronously = 0;

            for (int i = 0; i < 5; i++)

            {

                withoutExecuteSynchronously += Test(false);

                withExecuteSynchronously += Test(true);

            }

            Console.WriteLine((withoutExecuteSynchronously / (double)withExecuteSynchronously).ToString(“F2″));

        }

    }

}

This test creates a chain of NUM_CONTINUATIONS continuations, each of which does zero work, seeing how long it takes to execute the whole chain, and comparing the cases where the continuations are and are not created with the ExecuteSynchronously option.  On the laptop on which I’m writing this blog post, I see the ExecuteSynchronously version running faster, with at most a 2x difference in throughput.  This highlights why we made the ExecuteSynchronously option available even though it’s not the default.

Kommentare abgeschalten

Blog Platform Upgrades Happening this Week

16.05.2010 um 10:05 pm · Abgelegt unter .NET Help

Dear Parallel Computing Enthusiasts,

This week, Microsoft is rolling out a platform update to all blogs on the http://blogs.msdn.com site, including this one.  Comments on this blog will be disabled at approximately 9pm PST tonight and will be off until mid-day on the 24^th.  We also do not expect to publish any new blog posts during this time.  If you want to read a bit about some of the platform improvements that will be coming, Sean Jenkin’s blog is a good resource.

Thanks for your patience during this update. See you in a week!

Kommentare abgeschalten

Blog Platform Upgrades Happening this Week

16.05.2010 um 10:05 pm · Abgelegt unter .NET Help

Dear Parallel Computing Enthusiasts,

This week, Microsoft is rolling out a platform update to all blogs on the http://blogs.msdn.com site, including this one.  Comments on this blog will be disabled at approximately 9pm PST tonight and will be off until mid-day on the 24^th.  We also do not expect to publish any new blog posts during this time.  If you want to read a bit about some of the platform improvements that will be coming, Sean Jenkin’s blog is a good resource.

Thanks for your patience during this update. See you in a week!

Kommentare abgeschalten

Play

13.05.2010 um 7:54 pm · Abgelegt unter Internet Resources

Kommentare abgeschalten

ParallelExtensionsExtras Tour – #16 – Async Tasks for WebClient, SmtpClient, and Ping

05.05.2010 um 12:37 am · Abgelegt unter .NET Help

(The full set of ParallelExtensionsExtras Tour posts is available here.)  

The Task Parallel Library isn’t just about CPU-bound operations.  The Task class is a great representation for any asynchronous operation, even those implemented purely as asynchronous I/O.

Task’s ability to represent arbitrary asynchronous operations without tying up threads is rooted in the TaskCompletionSource<TResult> class (previously discussed here), and this becomes a building block for creating an unlimited number of higher-level asynchronous operations represented as a Task. ParallelExtensionsExtras includes a wealth of such implementations, and for the next several blog posts in this ParallelExtensionsExtras Tour series, we’ll examine several implementations as well as how they can be used in your own projects that require asynchrony.

The ParallelExtensionsExtrasExtensionsEAP folder contains three useful files: WebClientExtensions.cs, SmtpClientExtensions.cs, and PingExtensions.cs.  As you might guess, these files contain extension methods for the System.Net.WebClient, System.Net.Mail.SmtpClient, and System.Net.NetworkInformation.Ping classes.  These extension methods mirror the existing asynchronous methods on these types (which all implement the Event-Based Asynchronous Pattern), but rather than forcing you to first register for some events and then call a method to kick off the download, they simply return task-based representations.  For example, WebClientExtensions provides the following method, which will download the data at the specified address and return a Task<byte[]> to represent the result:

public static Task<byte[]> DownloadDataTask(

    this WebClient webClient, string address);

With a method like this, you can very easily download a single file, but you can now also take advantage of the power of the Task class to, for example, download multiple files and perform a follow-up operation asynchronously only when all of the asynchronous downloads have completed, in this case outputting some diagnostic information about each download’s success or failure, e.g.

Task.Factory.ContinueWhenAll(new[]

{

    new WebClient().DownloadDataTask(“http://www.microsoft.com”),

    new WebClient().DownloadDataTask(“http://blogs.msdn.com/pfxteam”),

    new WebClient().DownloadDataTask(“http://msdn.com/concurrency”)

},

tasks =>

{

    // All tasks completed; look at the result for each

    foreach (var task in tasks)

    {

        // Print out information about each download

        Console.WriteLine(“Address: “ + task.AsyncState);

        if (task.IsFaulted)

            Console.WriteLine(“tFailed: {0}”,

                task.Exception.InnerException.Message);

        else

            Console.WriteLine(“tDownloaded {0} bytes”,

                task.Result.Length);

    }

});

As another example, the PingExtensions class provides the extension method:

    public static Task<PingReply> SendTask(
        this Ping ping, string hostNameOrAddress);

This makes it easy to send multiple pings asynchronously and work with the resulting task objects, e.g.

var addresses = new[]

{

    “localhost”,

    “microsoft.com”,

    “msdn.com”

};

var pings = (from address in addresses

             select new Ping().SendTask(address)).ToArray();

foreach (var ping in pings)

{

    // Print out each ping as it succeeds or fails

    ping.ContinueWith(t =>

    {

        Console.WriteLine(“Ping for {0}: {1}”, t.AsyncState,

            t.IsFaulted ?

                t.Exception.InnerException.Message :

                t.Result.Status.ToString());

    });

}

Or by taking advantage of the ContinueWhenAny method, we can send out several pings and take action just when the first ping completes, e.g.

var pings = (from address in addresses

             select new Ping().SendTask(address)).ToArray();

Task.Factory.ContinueWhenAny(pings,

    ping => Console.WriteLine(“First ping completed: “ + ping.Result.Address));

In our next post, we’ll continue our exploration of using tasks for asynchrony.

Kommentare abgeschalten

ParallelExtensionsExtras Tour – #15 – Specialized Task Waiting

04.05.2010 um 8:58 pm · Abgelegt unter .NET Help

(The full set of ParallelExtensionsExtras Tour posts is available here.) 

The Task Parallel Library provides the Task.Wait method, which synchronously waits for the target Task to complete.  If the Task completed successfully, the method simply returns.  If the Task completed due to an unhandled exception or cancellation, Wait throws an appropriate exception to connote that you can’t just blindly continue expecting the results or side-effects of the Task to have taken place.

While this is a very useful form of waiting, there are others that can be beneficial in certain situations, and ParallelExtensionsExtras includes a few different forms in the TaskExtrasExtensions.cs file.

WaitWithPumping

In a Windows Presentation Foundation application, especially when doing unit testing, you sometimes need to wait for a task on the UI thread.  However, in doing so you don’t want to block the UI thread, and instead you want to continue the WPF message loop, maintaining a responsive application.  For this purpose, ParallelExtensionsExtras includes the WaitWithPumping extension method for Task.

public static void WaitWithPumping(this Task task)

{

    if (task == null) throw new ArgumentNullException(“task”);

    var nestedFrame = new DispatcherFrame();

    task.ContinueWith(_ => nestedFrame.Continue = false);

    Dispatcher.PushFrame(nestedFrame);

    task.Wait();

}

WaitWithPumping enters a message loop that will only exit when the task completes, which WPF knows about through a continuation applied to the task.  Once the message loop has exited, we Wait on the task simply to propagate exceptions in the case where the task did not complete successfully.

With that in place, you could write WPF code like the following:

private void button1_Click(object sender, RoutedEventArgs e)

{

    var t = Task.Factory.StartNew(() => Thread.Sleep(5000));

    t.WaitWithPumping(); // UI remains responsive during call

    MessageBox.Show(t.Status.ToString()); // will show “RanToCompletion”

}

Even thought Task t won’t complete for 5 seconds, and even though WaitWithPumping will block, the UI will still remain responsive.  Then, because we waited for the Task to complete before exiting the message loop, the MessageBox will show “RanToCompletion”.

WaitForCompletionStatus

Sometimes you want to wait for a Task, but you don’t want the Wait operation to throw an exception, even if the target task completed in the Faulted or Canceled states.  To achieve this, ParallelExtensionsExtras provides the WaitForCompletionStatus extension method on Task:

public static TaskStatus WaitForCompletionStatus(this Task task)

{

    if (task == null) throw new ArgumentNullException(”task”);

    ((IAsyncResult)task).AsyncWaitHandle.WaitOne();

    return task.Status;

}

This method relies on the fact that Task implements IAsyncResult, and thus implements the AsyncWaitHandle property.  AsyncWaitHandle returns a WaitHandle that will be set when the task completes, and waiting on this wait handle will not throw exceptions in the same manner as does waiting on the task directly.

WaitForCompletionStatus returns the final TaskStatus of the task that was waited on.  This makes it easy to write code that switches on a task’s completion state in order to do appropriate follow-up processing, e.g.

switch(task.WaitForCompletionStatus)

{

    case TaskStatus.RanToCompletion:

        Console.WriteLine(“Woo hoo!”);

        break;

    case TaskStatus.Faulted:

        Console.WriteLine(“Uh oh: “ + task.Exception.Message);

        break;

    case TaskStatus.Canceled:

        Console.WriteLine(“Oh well.”);

        break;

}

Kommentare abgeschalten

Coquette Part 8

04.05.2010 um 8:48 am · Abgelegt unter Internet Resources

Kommentare abgeschalten

A TPL Sandbox

03.05.2010 um 7:00 pm · Abgelegt unter .NET Help

In a previous post, we introduced the UnobservedTaskException event, saying that it would be useful for host-plugin scenarios where a host application should continue to execute in the presence of exceptions thrown by buggy plugins.  A typical example is an Internet browser; should the entire application crash if some rich content plugin crashes?  Today, we will describe how to achieve this scenario by creating a TPL sandbox using this feature in conjunction with application domains.

Application domains (represented by AppDomain objects) were introduced to .NET to provide isolation, unloading, and security boundaries in a single process.  For example:

// Create a PermissionSet for the sandbox AppDomain

PermissionSet permSet = new PermissionSet(PermissionState.None);

…

// Create an AppDomainSetup.

AppDomainSetup setup = new AppDomainSetup();

…

// Create the sandbox AppDomain

AppDomain sandbox = AppDomain.CreateDomain(

    “Sandbox”,

    null,

    setup,

    permSet,

    CreateStrongName(Assembly.GetExecutingAssembly()));

// Execute the BuggyPlugin assembly in the sandbox AppDomain.

try

{

    sandbox.ExecuteAssembly(“BuggyPlugin.exe”);

}

catch (Exception e)

{

    LogError(e);

}

AppDomain.Unload(sandbox);

In the above host code, the BuggyPlugin assembly is executed within a sandbox AppDomain.  The restricted permissions of the AppDomain prevent the plugin from stepping out of line, and the try/catch block around the call to ExecuteAssembly handles any synchronous exceptions that propagate from the plugin.  However, the key word is “synchronous”.  Asynchronous exceptions, like those thrown within Task bodies, will not propagate through this try/catch block.  If left unobserved, they will be treated as unhandled exceptions, tearing down the process by default.

The UnobservedTaskException event was added to continue to support this scenario.  The following code demonstrates how to subscribe to this event by specifying an initializer delegate for the plugin AppDomain.

AppDomainSetup setup = new AppDomainSetup();

setup.AppDomainInitializer = _ =>

{

    // Subscribe to the TPL exception event. Unobserved

    // Task exceptions will be logged and marked as

    // “observed” (suppressing the usual exception escalation

    // behavior which would crash the process).

    TaskScheduler.UnobservedTaskException +=

        (object sender, 
         UnobservedTaskExceptionEventArgs exceptionArgs) =>

    {

        LogError(exceptionArgs.Exception);

        exceptionArgs.SetObserved();

    };

};

With this addition, all unobserved Task exceptions that originate from the plugin code will be logged and marked as observed.  It’s important to note that there is one of these events per AppDomain.  This makes it possible to selectively squash Task exceptions from the plugin; exceptions that originate from the host will be treated normally (as serious errors that should stop the application’s execution).

Attached is the full code used in this post.  Enjoy!

Kommentare abgeschalten