int64.org

Microsoft, Page 2

User Mode Scheduling in Windows 7

Don’t use threads. Or more precisely, don’t over-use them. It’s one of the first thing fledgling programmers learn after they start using threads. This is because threading involves a lot of overhead. In short, using more threads may improve concurrency, but it will give you less overall throughput as more processing is put into simply managing the threads instead of letting them run. So programmers learn to use threads sparingly.

When normal threads run out of time, or block on something like a mutex or I/O, they hand off control to the operating system kernel. The kernel then finds a new thread to run, and switches back to user-mode to run the thread. This context switching is what User Mode Scheduling looks to alleviate.

User Mode Scheduling can be thought of as a cross between threads and thread pools. An application creates one or more UMS scheduler threads—typically one for each processor. It then creates several UMS worker threads for each scheduler thread. The worker threads are the ones that run your actual code. Whenever a worker thread runs out of time, it is put on the end of its scheduler thread’s queue. If a worker thread blocks, it is put on a waiting list to be re-queued by the kernel when whatever it was waiting on finishes. The scheduler thread then takes the worker thread from the top of the queue and starts running it. Like the name suggests, this happens entirely in user-mode, avoiding the expensive user->kernel->user-mode transitions. Letting each thread run for exactly as long as it needs helps to solve the throughput problem. Work is only put into managing threads when absolutely necessary instead of in ever smaller time slices, leaving more time to run your actual code.

A good side effect of this is UMS threads also help to alleviate the cache thrashing problems typical in heavily-threaded applications. Forgetting your data sharing patterns, each thread still needs its own storage for stack space, processor context, and thread-local storage. Every time a context switch happens, some data may need to be pushed out of caches in order to load some kernel-mode code and the next thread’s data. By switching between threads less often, cache can be put to better use for the task at hand.

If you have ever had a chance to use some of the more esoteric APIs included with Windows, you might be wondering why we need UMS threads when we have fibers which offer similar co-operative multitasking. Fibers have a lot of special exceptions. There are things that aren’t safe to do with them. Libraries that rely on thread-local storage, for instance, will likely walk all over themselves if used from within fibers. A UMS thread on the other hand is a full fledged thread—they support TLS and no have no real special things to keep in mind while using them.

I still wouldn’t count out thread pools just yet. UMS threads are still more expensive than a thread pool and the large memory requirements of a thread still apply here, so things like per-client threads in internet daemons are still out of the question if you want to be massively scalable. More likely, UMS threads will be most useful for building thread pools. Most thread pools launch two or three threads per CPU to help stay busy when given blocking tasks, and UMS threads will at least help keep their time slice usage optimal.

From what I understand the team behind Microsoft’s Concurrency Runtime, to be included with Visual C++ 2010, was one of the primary forces behind UMS threads. They worked very closely with the kernel folks to find the most scalable way to enable the super-parallel code that will be possible with the CR.

My Windows Vista/7/8 Wishlist

These are some changes I’ve been trying to get made since Vista entered beta. Now 7’s beta has begun and still chances look bleak. Maybe I’ll have more luck in 8?

• Remove TransmitFile/ TransmitPackets limitations. Added back in Windows NT 3.51, the TransmitFile function lets you transfer a file’s contents entirely in kernel-mode, directly out of Windows’ internal file cache. This requires significantly less resources, is much more scalable, and is simpler to code for. Later on we got the even more functional TransmitPackets function. So what’s the problem? Microsoft wanted to guard against people using their desktops as servers: they locked desktops down to handling two concurrent TransmitFile calls at once. With increasingly faster internet connections and P2P’s popularity still rising, this just won’t fly anymore. For what would probably take less than five minutes to change, Microsoft could make Windows seem faster for so many people.
• Give me asynchronous DNS! Vista teased me with the GetAddrInfoEx function, which has unimplemented placeholders for async functionality. I wonder how much faster browsing the web would be if a browser submitted several DNS requests at once, instead of one at a time? Think of all those nasty Web-2.0 sites that load things from 10 different hostnames, or forum sites that let users display external images.
• Implement Linux’s TCP_CORK. It forces TCP to send out full frames only—no partials. Think of it like Nagle without the timeout. In some situations this can result in higher throughput, so I’m all for it.
• Allow me to bind sockets and files to a thread, for I/O completion ports. It could be very nice to set a preferred thread for I/O packets to arrive on, with work stealing settings. This could improve scalability by helping applications better specify their usage patterns.
• Let me boot from software RAID. I have yet to see a quasi-hardware RAID solution (you know, the ones that come with your $80 desktop motherboard) that doesn’t suck. These things do most—if not all—of the work in software drivers, and every single one I’ve seen has brought performance and stability issues along with it. Windows has it’s own built-in software RAID which should alleviate the need for all this cheap unstable crap. Unfortunately the one big gotcha of full software RAID is that you can’t boot from it. Come on guys, Linux has been letting me keep the bulk of my system in software RAID for a long time now. Time to play catch up.

Windows 7 Beta will be free to the public

Not part of the one of the Windows 7 beta teams? On January 9th, the first 2.5 million people to visit the Windows 7 homepage will be able to download the beta for free.

I just got my copy installed a few hours ago, so far I’ve seen a few new features I like and couple that I’m not sure about. I will blog about specifics as soon as I’m certain what I’m allowed to mention.

And so, the Windows 7 tech beta begins.

Got my invite to the Windows 7 tech beta today. The first beta won’t be out until early 2009, but from what I’ve heard the current internal copies of Windows 7 are already a pretty good improvement over Vista, in both performance and usability. Looking forward to working with all the fine folks I’ve met from the last few betas!

C#: lamer by the moment

To my disbelief, you can’t inherit from generic type parameters in C#. Something like this is currently impossible:

class Foo<T> : T
{
}

It’s sad, really, how Microsoft continues to focus on other crap but leaves out basic things like constraint-based overload resolution or simple inheritance. And still no Spec# features.

Visual Studio 2010 CTP now available

Coinciding with the 2008 PDC, the first Visual Studio 2010 CTP is now available for download. At first glance, it includes a few interesting things for C++:

• Partial C++0x support: lambda expressions, rvalue references, static assertions, and “auto” are now supported.
• Revamped IntelliSense: now faster and more accurate.
• Parallel Pattern Library: a modern C++ library that allows easier and safer use of today’s multi-threaded computing.

I’ll be posting more as I take a closer look at these and other features.

More on Japanese in Windows

If you just ripped your Japanese music collection only to find out Windows Explorer can’t display any of the tags, you probably used ID3 v2.4. Windows does not support 2.4—if you downgrade the files to ID3 v2.3, everything will display just fine. A good tool that can do this en masse is Mp3tag. This doesn’t only affect the UTF-8 fields: Windows won’t be able to read album art or anything else if you use v2.4.

Visual Studio incompatibilities

Hopefully someone reading this won’t have to waste a few days trying to figure this stuff out:

If you install Visual Studio 2008 Team Explorer, you’ll want to install it before VS2008 SP1 or stuff will break.

Internet Explorer 8 Beta 2 breaks the Windows Mobile 6 SDK Refresh—try to click on Platforms in the project creation wizard, and it’ll cancel the dialog. Uninstalling IE8 (Control Panel->Programs->View installed updates->Windows Internet Explorer) fixes the issue.

Adding Japanese support to Windows Mobile 6.1

The Windows Mobile 6.1 update just hit for my Blackjack II, and I’m liking it quite a bit. One problem, though, is that it seems to lack any Japanese fonts for the UI – everything shows up as those familiar boxes. Here’s how to add the Meiryo font from Vista to your phone.

Caveat lector: this involves modifying the registry on your phone. If you aren’t completely confident in your abilities with this, don’t do it. I’ve only done this on my AT&T Blackjack II running the Windows Mobile 6.1 update. Phones are pretty damned expensive, don’t blame me if you break yours!

You will need:

• Mobile Registry Editor
• Windows Mobile Device Center(6.1 or higher)

First you need to grab the font files from Vista, out of your Windows\Fonts dir. Explorer doesn’t let you do this, so you can go via command line or any other app with a Open File window or something similar. You are looking for meiryo.ttc and meiryob.ttc. Once you’ve got these, copy them to your phone’s Windows\Fonts dir.

Next you’ll need to perform some registry edits on your phone. Open up Mobile Registry Editor and go to HKEY_LOCAL_MACHINE\Software\Microsoft. Right click, and go to New->Registry Key. Enter FontLink for the name. Inside of the FontLink key, add another key called SystemLink.

Inside the SystemLink key, right click and go to New->Multi-String Value. For the Value Name, enter Segoe Condensed. For the Value Data, enter windows\fonts\meiryo.ttc,Meiryo. To my knowledge Segoe Condensed is the only font used in the UI on Windows Mobile 6.1, but you can repeat this step replacing Segoe Condensed with any fonts you want to add Japanese support to.

Now go back to HKEY_LOCAL_MACHINE\Software\Microsoft. Add a new key called FontPath. Inside this key, right click and go to New->String Value. For Value Name, enter FontPath. For Value Data, enter windows\fonts.

Now just reboot the phone and it should have Japanese support throughout the UI!

RTM hits for SQL Server 2008, Visual Studio 2008 SP1, .NET 3.5 SP1

SQL Server 2008, Visual Studio 2008 SP1, and .NET 3.5 SP1 have all been RTMed!