Arun Kishan: Inside Windows 7 - Farewell to the Windows Kernel Dispatcher Lock

Play Arun Kishan: Inside Windows 7 - Farewell to the Windows Kernel Dispatcher Lock

The Discussion

  • User profile image

    The interview I have been dreaming of, and about, and over and...


    I really do mean that!

  • User profile image



    Enjoy! What Arun accomplished really is amazing. I'm just blown away by the elegance of his solution and the engineering strategies he employed to pull it off (you'll learn about those towards the end of the conversation).



  • User profile image

    Blimey, you've certainly got to have had your head in the kernel for awhile to really keep up with that, but by the end I understood the general concept, and it sounded impressive Wink.

  • User profile image

    Truly amazing! Really interesting stuff, thanks Charles.

    This is fascinating to see how, with such talented people, a kernel designed more than decade ago can be enhanced to suit today's needs. This is why I love Operating System design and programming. There are such great foundations and languages to build upon but also so many improvements to do. 

  • User profile image

    wow, video start-to-whiteboard (STW) in 33 seconds, good stuff Smiley

  • User profile image

    I am a C# Developer who has always worked with Locking, Threads, etc through .NET and never through C++ libraries.  Even though that is the case, would it not help optimization to have a mechanism for the developer to suggest/hint to the OS an okay timeframe for a long running Wait to be loaded back from Paged Memory?  In other words, a developer may know it is never important for a certain Thread to be running again for let us say 15 days.  Consequently, she/he can add a TimeSpan argument to his Thread Function/Method that gives a hint to OS that while it might be less than 15 days that Thread says it now wants to run because Wait was satisfied or whatever; he is okay with it taking up to 15 days.  Then, the OS could decide based on OS Processor's resources to not have to pay any attention to this Job/Thread running again in Non-Paged Memory if 15 days has transpired.  If OS Resources are at a very low rate of utilization and there is plenty to go around for all Threads/Processes, it could then check this Thread/Job to see if it wants to run sooner than 15 days.


    Does this make sense?  If it does, is this already built into Windows 7 or even Vista/XP?  The basic thing I am trying to say is to give the OS a shortcut to skip over Thread Wait checks if resources are very low.  In other words, the Threads with hints like those that I mention above could be set aside completely in Paged Memory or even to Disk if there were many demands on resources and not even have to be checked to see if they need to run if need be.  Then, when resources were plentiful, they could be checked to see if they might want to be run and initiated at maybe a time where OS is, running yet User(s) are in bed, not at Server/Computer, etc.


    It would be analogous to a Doctor triage where the Doctor could say, Yes, No, Revisit in 2 hours if you have time yet do not even think about this guy/gal unless you have nothing else to do.

  • User profile image

    Hi MaidenDotNet,

    The OS will already page out your stacks/process after some time of inactivity.  I believe a thread becomes a candidate after about 4 seconds. Once the pages become a candidate for theft, then it's only a matter of time and memory pressure when the Memory Manager will rip them away and use them for something else. 


    Basically, you don't need to give a 'hint' to the OS since it will do what you want on its own.  On the other hand, if you want the thread to run quickly when it gets signaled, you may be in trouble because of this behavior.  If the pages make it to the disk, it could take about 10-15 milliseconds between when your thread is activated and when it can run (this is the typical seek time of a laptop disk). If the disk is already busy, it could take even longer.

  • User profile image

    Wow, Its just amazing. The solution and strategies are really impressive, n i hope dt would be scalable as well for upcoming core technologies

  • User profile image
    omkar K

    Really nice enhance ment in the code ....

    Phenomenal ...

  • User profile image

    Excellent work


    We can now expect windows to really scale


    Keep it up


  • User profile image
    Brian Hartung

    Fascinating.  I would be interested to know what Dave Cutler's take on all this was.  Was he involved in any of the early discussions?  Did Arun formulate the solution first and take it to him (formally or informally)?  Did he say "wow, great idea!" or perhaps "nice try Rookie, but you forgot to assert the make-it-work bit on line 24"...or (perish the thought) did he get all defensive about his baby and start mumbling about Reagan-era priorities... Smiley  This interview is the very essence of why Channel 9 rocks...

  • User profile image

    Glad you enjoyed this! Yes, Cutler was briefed and blessed the change. After all, it was his code/design that Arun replaced Smiley Arun is a genius.



  • User profile image

    I my company we develop light simulation software based on the physics of the photon interaction with the matter. We use itensively multithreading.
    I did some performance tests to compare Vista and Seven on a 16 core, dual boot Vista/Seven.
    The result is a consternation :
    - same 16 threads using TLS : 18% slower on Seven
    - same 16 threads using std:map per thread data : 2x slower on Seven
    - same 16 threads using only local variable on stack and only doing only math operations : 38% slower on Seven.
    Moreover : on Vista all threads finishes nearly at the same time, it is no more the case on Seven. On Seven the threads finish one after each other (after a long time), and when only 1 thread remains, it switches from 1 core to another one randomly (I do not set the affinities in this test).
    I am continuing my tests with critical sections, interlock instructions...

Add Your 2 Cents