Released! Parallel Extensions to the .NET Framework June 2008 CTP

Released! Parallel Extensions to the .NET Framework June 2008 CTP

Rate This
  • Comments 47

We’re very excited to announce our 2nd Community Technology Preview (CTP) for Parallel Extensions to the .NET Framework 3.5.  We released the Dec07 CTP on 11/29/2007, and from that we have received a lot of feedback from the community and customers.  While you have been using our bits, participating in our forums, sharing your insights and experiences, and following along on our blog, we have been hard at work preparing this CTP, incorporating your feedback into it.

 

Download the Parallel Extensions June 08 CTP (UPDATE 11/30/09: The June 2008 CTP is no longer available.  For an unsupported release of Parallel Extensions compatible with the .NET Framework 3.5 SP1, please see the Reactive Extensions release on DevLabs at http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx.)

 

There are some large changes in there that should provide a lot of benefits.  First off, we have begun to add the third major API component, the Coordination Data Structures, to the technology package.  As we build PLINQ and the Task Parallel Library, we use a lot of components under the covers to handle synchronization, coordination, and scale to contain data reads and writes from multiple procs.  We see these as widely useful, so we’re sharing them here with you.

 

We incorporated a brand-new user-mode, work-stealing, run-time scheduler (those modifiers essentially mean that it’s light, fast, and flexible) to the system, completely over-hauling the infrastructure.  This is a very important piece of technology for making the most of the resources available on your machines.  This has been in research and incubation for a long time, and it will allow for improved performance and future-proof scalability (e.g. cache consciousness) as we stabilize and improve it.  Expect to hear us talk a lot more about this in the future.  There are still likely to be some growing pains in this release, so please pass along that feedback and expect this to improve.  Additionally, The Task Parallel Library is now built directly on top of this scheduler.  And to add to the excitement, PLINQ is in the first stages of building on top of the Task Parallel Library. 

 

There are a number of other changes that we have made, some notables include: new ordering implementation for PLINQ, change of Parallel.Do to Parallel.Invoke, continuations in Tasks.  A much more detailed list of updates is coming soon. 

 

Subscribe to the feed or come back to this blog often as we release a flurry of posts regarding the new and exciting work surrounding this CTP.

Leave a Comment
  • Please add 5 and 4 and type the answer here:
  • Post
  • PingBack from http://code-inside.de/blog/2008/06/09/wchentliche-rundablage-silverlight-2-wpf-aspnet-mvc-jquery/

  • PingBack from http://code-inside.de/blog-in/2008/06/09/wchentliche-rundablage-silverlight-2-wpf-aspnet-mvc-jquery/

  • l'equipe PFX, vient d'annoncer la disponibilité de la deuxième CTP du framework parallèle pour .NET blogs

  • PingBack from http://tempuzfugit.wordpress.com/2008/06/12/publicada-la-parallelfx-ctp-junio-2008/

  • at 06/02, Microsoft just released the latest CTP of Parallel Extension to .NET 3.5 (as PFX later), available

  • crosspost from http://blogs.msdn.com/rextang at 06/02, Microsoft just released the latest CTP of Parallel

  • When I run the following test in NUnit, I get this exception when NUnit has finished running all tests:

    Unhandled Exception:Unhandled Exception:  System.AppDomainUnloadedException: The

    application domain in which the thread was running has been unloaded.System.App

    DomainUnloadedException: The application domain in which the thread was running

    has been unloaded.

    The program works as expected when run as a console application. Is there a workaround?

    using System;

    using System.Threading;

    using NUnit.Framework;

    namespace Tests

    {

       [TestFixture]

       public class ParallelExtensionsTest

       {

           [Test]

           public void FirstTest()

           {

               Parallel.Invoke(

                   () => A(),

                   () => B());

           }

           private static void A()

           {

               Console.WriteLine("A");

           }

           private static void B()

           {

               Console.WriteLine("B");

           }

       }

    }

  • It looks like the exception Casper indicated above happens whenever parallel extensions were used from app domain which later got unloaded. Here's a simple example to replicate this:

    using System;

    using System.Reflection;

    using System.Threading;

    public class Program : MarshalByRefObject

    {

       private static void Main()

       {

           AppDomain appDomain = AppDomain.CreateDomain("Moo");

           var p = (Program) appDomain.CreateInstanceAndUnwrap(

                                 Assembly.GetExecutingAssembly().FullName,

                                 "Program");

           p.ParallelTest();

           AppDomain.Unload(appDomain);

       }

       public void ParallelTest()

       {

           Parallel.Invoke(() => Console.WriteLine("Leet!"));

       }

    }

    Any ideas how to avoid this?

  • I found another problem. After the parallel operations are performed, the Parallel Extensions library does hog the CPUs. Even for my simple test program below, it uses up to about 1/3 of my 4 Xeon cores long after the operations are performed. It doesn't seem to ever stop. The CPU load is about evenly distributed accross all cores. Both Parallel.For and Parallel.ForEach has this problem. My OS is Windows Server 2003. Is there a fix or workaround available?

    using System;

    using System.Threading;

    namespace ParallelExtensionsConsole

    {

       public class Program

       {

           static void Main(string[] args)

           {

               Console.WriteLine("Call Parallel.For (y/n)?");

               var key = Console.ReadKey();

               Console.WriteLine();

               if (key.KeyChar == 'y')

               {

                   Parallel.For(0, 10, i =>

                                           {

                                               Console.WriteLine(i);

                                           });

               }

               Console.WriteLine("Press any key to continue...");

               Console.ReadLine();

           }

       }

    }

  • re: AppDomain

    Yes, the scheduler in the CTP doesn't handle thread aborts very well, which frequently causes the process to crash when a live scheduler exists in a domain being shutdown (since AppDomain shut down causes thread aborts on all threads with stack frames in that domain).  We're working to harden this for a future release.  The work around is to ensure that any schedulers in the domain are disposed of and shutdown before the domain is shut down; unfortunately, since by design the default TaskManager, the workaround requires always explicitly using a new TaskManager instance, so as to avoid lazily-initializing the default TaskManager instance.

    re: Another problem

    Yes, thanks for reporting it.  This is a known issue with how the scheduler searches for work; there's a bug that causes it to sometimes get stuck in a polling loop, which manifests as the CPU usage you're observing... definitely being addressed for a future release.

  • nqlWmb  <a href="http://aesfvzthsyfe.com/">aesfvzthsyfe</a>, [url=http://lwyavtckbnus.com/]lwyavtckbnus[/url], [link=http://mibkqvrbxkru.com/]mibkqvrbxkru[/link], http://zyknscndeabj.com/

  • PingBack from http://khason.net/blog/just-released-parallel-extensions-%e2%80%93-june-ctp/

  • Re: The app domain "workaround" - this doesn't work. I used Reflector to take a look at the assembly, and the default TaskManager is not lazily initialized, so you can't create a TaskManager instance without also creating the default one.

    However, for NUnit you can work around this by copying the NUnit console exe and the various assemblies it needs into the same directory as the assembly containing the tests you wish to run, then specify  /domain:None when you run it.

  • I'm having trouble testing PLINQ code or using PLINQ to make parametric tests run faster. NUnit consistently throws AppDomainUnloadedException after the tests. I've tried many workarounds suggested in this thread and elsewhere, to no avail.

    What's happened in the last 14 months to make AppDomainUnloadedException easier to avoid, diagnose, and — ideally — prevent?

    Yours,

    Garth.

  • @Garth - Thanks for the comments.  We have spent nearly a whole cycle of development since this CTP.  We have done a lot of work around the reliability of parallel extensions including exception handling in AppDomain unload cases.  Please try this out on Beta 1 of the .NET Framework 4 to see if this issue persists.  Additionally, we have taken a few more fixes in AppDomain unload since Beta 1, and they should be available in an upcoming release of the Framework.  

    You can download Beta 1 here:

    http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ee2118cc-51cd-46ad-ab17-af6fff7538c9

Page 3 of 4 (47 items) 1234