none
Change TaskManager on PLINQ queries

    Question

  • I'm under the assumption that in previous CTPs that option was available. In the latest CTP, is there any way to do that?
    btw, in case you're wondering why I'm not specifying the DOP, it's because my code will run in hosts which might need to throw thread abort expcetions and in this case I believe that the only workaround is to explicitly discard the TaskManager used - which can only be done if I control the one that is being used)

    thanks.


    Luis Abreu
    Friday, April 17, 2009 1:15 PM

Answers

  • PLINQ will not provide a mechanism that allows the TaskManager to be altered, particularly because it is far too easy for a custom scheduler to break the guarantees that PLINQ relies on.

    Regarding your scenario, however, there are significant issues with allowing ThreadAborts to be thrown at arbitrary code, and PLINQ is not hardened to work in such situations.  For example, even if the Tasks can cope with ThreadAbort, the internals of PLINQ may be arbitrarily scrambled due to critical sections getting aborted midway and leaving inconsistent state.

     

    Can you give provide more details about the situation you wish to use PLINQ?

    Friday, April 17, 2009 9:04 PM
  • Hi Luis,

    The default task Manager has been fixed to shutdown cleanly on AppDomain unload. This means you will no longer need to create a custom task scheduler to get the ASP.NET scenario working. 

    As I mentioned earlier, we have found that it is hard to ensure custom schedulers provide all guarantees that PLINQ needs. As part of Beta1, we are thinking of removing the support for custom task schedulers in PLINQ. Is there any other scenario where you will need to use a custom task scheduler?

    Thanks,
    Pooja

    Friday, April 17, 2009 10:47 PM

All replies

  • PLINQ will not provide a mechanism that allows the TaskManager to be altered, particularly because it is far too easy for a custom scheduler to break the guarantees that PLINQ relies on.

    Regarding your scenario, however, there are significant issues with allowing ThreadAborts to be thrown at arbitrary code, and PLINQ is not hardened to work in such situations.  For example, even if the Tasks can cope with ThreadAbort, the internals of PLINQ may be arbitrarily scrambled due to critical sections getting aborted midway and leaving inconsistent state.

     

    Can you give provide more details about the situation you wish to use PLINQ?

    Friday, April 17, 2009 9:04 PM
  • Hi.

    Well, I'm using it to parallelize an expensive operation in a WCF service which is hosted on an ASP.NET site. I've noticed in the Parallel team's blog that this is a know problem and the workaround was to use a custom TaskManager and make sure it was disposed when the thread aborted exception (which i believe might be thrown with an apdomain unload, right?).

    Now, since the algorythm was a LINQ query, I thought that the easiest thing would be to convert it to PLINQ. Now, I can also use a parallel.For and then I might create a new taskManager and have complete control over its lifetime (though I'll have to change my code slightly), but I'll only do that if I can get confirmation that it will work in my scenario (WCF service hosted in ASP.NET site).

    thanks again
    Luis
    Luis Abreu
    Friday, April 17, 2009 9:23 PM
  • Hi Luis,

    The default task Manager has been fixed to shutdown cleanly on AppDomain unload. This means you will no longer need to create a custom task scheduler to get the ASP.NET scenario working. 

    As I mentioned earlier, we have found that it is hard to ensure custom schedulers provide all guarantees that PLINQ needs. As part of Beta1, we are thinking of removing the support for custom task schedulers in PLINQ. Is there any other scenario where you will need to use a custom task scheduler?

    Thanks,
    Pooja

    Friday, April 17, 2009 10:47 PM
  • cool. do you know when will we have access to that release (that has fixed the AppDomain unload scenario)?


    Luis Abreu
    Monday, April 20, 2009 9:23 AM