none
Oversubscribe and UmsThreadDefault

    Question

  • What is the relationship between Concurrency::Oversubscribe and UmsThreadDefault? Is Concurrency::Oversubscribe an unnecessary overhead if I'm running the UMS scheduling policy?
    Friday, October 21, 2011 10:14 PM

Answers

  • Hi,

    UMS support in Concrt is being retired because although it's super fast at context-switching, well-structured parallel programs shouldn't do a lot of context switching.  In other words, in most real PPL scenarios, the UMS scheduler wasn't any faster than the regular Win32 thread scheduler.


    ++don;
    • Marked as answer by Dragon89 Thursday, October 27, 2011 10:49 PM
    Thursday, October 27, 2011 4:36 PM
    Owner

All replies

  • Hi,

    As you may know from reading other forum entries here, the UMS scheduler is being retired, and eventually choosing UmsThreadDefault will just end up using the Win32 thread scheduler.

    However, with that said, let's assume you really are running on a functional UMS scheduler.  In that case Oversubscribe does nothing, so there's actually no overhead.  It's also safer to use it and have it do nothing than it is to elide it when you actually might need it.  Putting it there gives you a little insurance just in case you ask for a UMS scheduler and you didn't get one (say, you're running on a non-UMS-capable OS).

    I hope that helps.


    ++don;
    Friday, October 21, 2011 10:28 PM
    Owner
  • Thank you for your answer. I am new to ConcRT and haven't heard about UMS being retired. Would you mind linking somewhere where I can read more about that?
    Friday, October 21, 2011 11:32 PM
  • Hi,

    ..........

    As you may know from reading other forum entries here, the UMS scheduler is being retired, and eventually choosing UmsThreadDefault will just end up using the Win32 thread scheduler.

    ........

    Interesting!Is it retired because of better technology coming or because it was buggy? Some time ago in this forum I posted some messages about crashes I had using UMS on both Win 7 64 bit and Windows Server 2008 R2 x64. I wasn't ever able to figure out why I had the crashes because the same exact code using normal threads has no issues...

    G.

     

    Monday, October 24, 2011 1:22 AM
  • I prefer OpenMP which everybody likes. It scales all the way up.

     


    Windows MVP 2010-11, XP, Vista, 7. Expanding into Windows Server 2008 R2, SQL Server, SharePoint, Cloud, Virtualization etc. etc.

    Hardcore Games, Legendary is the only Way to Play

    Developer | Windows IT | Chess | Economics | Vegan Advocate | PC Reviews

    Thursday, October 27, 2011 12:51 AM
  • .......

    I prefer OpenMP which everybody likes. It scales all the way up.

    .......

    I never liked the #pragma things... C++ PPL just feels right :)

     

    G.

    Thursday, October 27, 2011 2:23 AM
  • Its widely supported

    #pragma once

    is used in place of the #if block etc

    # is the preprocessor

     


    Windows MVP 2010-11, XP, Vista, 7. Expanding into Windows Server 2008 R2, SQL Server, SharePoint, Cloud, Virtualization etc. etc.

    Hardcore Games, Legendary is the only Way to Play

    Developer | Windows IT | Chess | Economics | Vegan Advocate | PC Reviews

    Thursday, October 27, 2011 11:07 AM
  • Hi,

    UMS support in Concrt is being retired because although it's super fast at context-switching, well-structured parallel programs shouldn't do a lot of context switching.  In other words, in most real PPL scenarios, the UMS scheduler wasn't any faster than the regular Win32 thread scheduler.


    ++don;
    • Marked as answer by Dragon89 Thursday, October 27, 2011 10:49 PM
    Thursday, October 27, 2011 4:36 PM
    Owner
  • Though, the UMS schedular isn't just about fast context-switching is it? 

    What about support for blocking operation inside threads?

    For example, I am now in a situation where I need to call a function from a third-party library (could be anything, e.g. win32) where I don't know whether the function will block or not. To be on the safe side I need to oversubscribe, although this results in lower performance in the case where it wasn't necessary. Using the UMS scheduler I wouldn't need to worry about this, if it blocks then oversubscribe otherwise run efficiently without oversubscription.

     

    Saturday, December 03, 2011 1:18 PM
  • <quote>

    UMS support in Concrt is being retired because although it's super fast at context-switching, well-structured parallel programs shouldn't do a lot of context switching.  In other words, in most real PPL scenarios, the UMS scheduler wasn't any faster than the regular Win32 thread scheduler.

    </quote>

    I don't think this is a good reason. You could use the concurrency runtime to implement for example an actor based system where every actor logically has it own thread of control (but without using physical threads). This is well studied and very deterministic programming model, but in this case you'll have a lot of context switches.



    Friday, December 28, 2012 11:36 AM