Translate This Page
Translate this page
Email Blog Author
RSS for posts
RSS for comments
Search this blog
Search all blogs
Testing Fiber Mode
Testing Fiber Mode
Testing Fiber Mode
26 May 2004 11:48 AM
Testing Fiber Mode Fiber mode is one of the interesting new features we’ve done in hosting. Fiber support in .NET comes up as a common question too. I’d like to give an overview of what we’ve done to test fiber mode to ensure that you’ll get a good experience if you choose to use it – and however you choose to use it.
To test fiber mode we created a test harness (called HostDriver) which could host the CLR. HostDriver supports a wide number of options, but the one I’ll focus on today is the ability to plug-in a user-defined set of managers. Those managers include things like a task manager (IHostTaskManager), a synchronization manager (IHostSynchronizationManager), a threadpool manager (IHostThreadpoolManager), an I/O completion manager (IHostIoCompletion) and several others. These managers can be mixed and matched from multiple DLLs, or they can all reside in the same DLL. HostDriver merges them together and presents a unified host to the CLR.
Once I had this infrastructure built the next task was to create a set of managers to plug-in. The initial one is obvious: Create a task manager that is a thin wrapper over the Win32 APIs. This provides a nice, simple task manager that is easy to debug (this is important!) when things go wrong. Unfortunately it doesn’t do nearly a good enough job of exercising the hosting APIs. So once this one was up and running I moved onto implementing a fiber task manager to run in this environment. As you may imagine, that was a lot of fun (and certainly was challenging).
There were a few really great things about this test harness. It allowed us to get broad coverage across how the threading APIs are changed when hosted. It allowed us to get broad coverage across how the programmer uses the hosting APIs. Finally it allowed us to get broad coverage of the various features running in fiber mode.
The first tests were the threading tests running inside the hosted environment. Obviously the threading tests are some of the most interesting because fiber mode is primarily changing the threading model. This includes things like exercising the thread-pool, synchronization, starting threads, aborting threads, etc… Today we exercise a large amount of threading functionality in our automation test passes to ensure this doesn’t regress.
The second win was the ability to cover the matrix of mixing and matching various managers. Want to use just a memory manager? That works. How about a memory manager and a thread pool manager? That works too. How about I/O completion and synchronization? Absolutely! Again, these tests make it into automation to ensure we don’t regress in these areas.
Want to use a task manager that’s running in fiber mode but not a synchronization manager? Don’t do that – your locks won’t be aware of what threads they’re running on! This is a fact that’s easy to overlook when you’re first implementing a fiber mode task manager. Unfortunately the runtime cannot detect this (and therefore it cannot be tested) but it is something you’ll need to consider when using the new hosting interfaces in fiber mode. If you think about it this makes sense: The threading and synchronization APIs need to be aware of what the other one is doing to function correctly.
And the final win was the ability to get broad coverage across all the product features running in fiber mode. This came to life in the form of a tool called Hostify and HostDriver’s evil cousin HostDriverDll. Hostify provides a mechanism to alter the CLR’s shim to allow the execution of arbitrary EXEs in a hosted environment. This allowed us to modify a machine and then run a normal test pass that would automatically run in a fiber environment. We can quickly cover a large portion of our code base in Fiber mode with minimal effort allowing us to run large fiber mode test passes. Unfortunately this is a long test pass that can’t just be put into our daily automation like another test. But before major releases (eg, alphas, betas, RCs, full releases) we do a full test pass that ensures that there have been no regressions introduced.
So that’s the short version of how we’ve worked to ensure that fiber mode is a solid feature. We’ve strived to test both the essential APIs in depth and get broad coverage across the feature set of the product. The matrix of possibilities is intense in the hosting layer but this effort should make your experience with them more pleasant.
Blog - Comment List MSDN TechNet
© 2015 Microsoft Corporation.
Privacy & Cookies