Why does Win32 even have Fibers?

re: Why does Win32 even have Fibers?

Edward — Thu, 06 Jan 2005 00:43:00 GMT

I first found out about fibers from reading Chris Brummes excellent but lengthy blog post on CLR hosting.
http://blogs.msdn.com/cbrumme/archive/2004/02/21/77595.aspx
I'm glad to see some more information being posted.

Its amazing how much I feel I've learned through these blogs in the last year. Yours and Raymonds especially. There seems to be very little information on these low level details of the OS.

I have copy of the new edition of Windows Internals on its way to me, should be an interesting book to dip into for those who want to understand more about how things work under the covers.
http://www.amazon.com/exec/obidos/tg/detail/-/0735619174/102-2480567-1461732?v=glance

re: Why does Win32 even have Fibers?

John Vert — Thu, 06 Jan 2005 01:18:00 GMT

On a somewhat historical note, the real reason we added fibers was not to give people control over their threads. Heck, it's your thread, you've got control, just allocate some memory for a stack then set ESP to point to it. Lots of people tried this, but it's not quite that simple. There are a lot of subtleties to get wrong. For instance, they would switch the stack base, but not update the stack limit. Or not switch the exception handler list. Or forget to swap the FP state. And down the line these little gotchas would bite them in some subtle unforeseen way.

Since people kept getting it wrong (and in fact, it was not possible to get it right without doing some fairly undocumented stuff) and causing untold grief, we figured it was time to build it into the OS and let everybody use.

Sometimes this is how APIs get created. Customers keep trying to do something that should be simple but is really much harder than it appears at first. So we make an API that encapsulates the subtle hard stuff.

Another BIG reason context switches are bad is because they are serialized. So even if you have a 32-CPU machine only one CPU can be context-switching at a time. The more context switches your app does the worse it scales. Fiber switches do not acquire any locks, therefore they will scale much better.
-John (ex-NT kernel dev without a blog)

re: Why does Win32 even have Fibers?

Larry Osterman — Thu, 06 Jan 2005 01:47:00 GMT

John,
Thanks for the update, it's appreciated.

re: Why does Win32 even have Fibers?

Fox Cutter — Thu, 06 Jan 2005 02:37:00 GMT

This is enlightening, I was under the impression that Fibers were added to Windows to help with porting UNIX Server applications. In particular applications that already have there own threading logic.

It's pretty clear I'm wrong about that , and it's nice to know the real reasons.

Thanks for the enlightening post.

--Fox Cutter

re: Why does Win32 even have Fibers?

Norman Diamond — Thu, 06 Jan 2005 02:44:00 GMT

> just for the sake of argument, let's say a
> context switch takes 5000 instructions

As you say that's just a guess, which is no problem. My guess is faster by an order of magnitude though. The rough estimate that I had heard was that servicing a page fault takes about 5000 instructions, and that's doing a lot more than other kinds of context switches.

By the way Microsoft Japan doesn't distinguish between page faults (ordinary happenings which can be remedied properly) and invalid page faults (resulting from bugs, resulting from pointers that got corrupted by various famous means or occasionally by actual bugs in the same program that was actually crashing). I think engineers do know the difference though.

re: Why does Win32 even have Fibers?

Larry Osterman — Thu, 06 Jan 2005 04:24:00 GMT

Norman, I believe that you're off by several orders of magnitude on the cost of a page fault. Page faults instruction counts can run from the thousands of instructions to the millions of instructions (depending on what had to happen).

After all, a page fault is likely to have to hit the disk (assuming that the page wasn't available in transition pages list), and when that happens, you might be looking at 2-200ms of time. There's a LOT of instructions in 200ms, even on a 100MHz processor.

'MS Japan' is a bit unspecific

Sam — Thu, 06 Jan 2005 10:00:00 GMT

Norman, Who is 'Microsoft Japan' you are talking about?
Is there an official MS document stating for all MS Japan workers 'thou shall not distinguish between page faults and invalid page faults' or is it someone working at MS Japan who did not distinguish between these two?

Sam

re: Why does Win32 even have Fibers?

Norman Diamond — Fri, 07 Jan 2005 01:01:00 GMT

1/5/2005 8:24 PM Larry Osterman

> After all, a page fault is likely to have to
> hit the disk

Of course but that's elapsed time not instruction count. The CPU still gets to do useful work for other purposes during that time.

1/6/2005 2:00 AM Sam

> Norman, Who is 'Microsoft Japan' you are
> talking about?

If you're not satisfied with the English name for that company then hypothetically I should type the name in Japanese, but the server that hosts this blog has corrupted Japanese words that I have typed in the past. Sorry.

> Is there an official MS document stating for
> all MS Japan workers

I don't know, the visible appearance of Windows is publicly visible but a lot of official MS documents aren't publicly visible. Even official MS documents which prove that OEMs are supposed to be responsible for supporting customers who get hit (sometimes very seriously) by MS bugs in MS Windows, aren't publicly visible. So sorry, I don't know.

re: Why does Win32 even have Fibers?

Larry Osterman — Fri, 07 Jan 2005 01:08:00 GMT

Norman, actually it IS instruction count - if there are other runnable tasks on the system, they'll be executing instructions.

I stand by my claim that context switches are less expensive than page faults (and I'm sure that the perf experts on the base team will correct me if I'm out of line :))

re: Why does Win32 even have Fibers?

James — Fri, 07 Jan 2005 01:59:00 GMT

This is slightly off topic, but would you please comment on SwitchToThread being identical to Sleep(0)? The documentation suggests that the latter leaves the thread in a 'ready' state, wheras the former yields to another thread that's ready to run and returns an indication of whether it's successful.

So far, so similar, but a specific consequence of using Sleep, as I read it, is that it will only relinquish to threads of an equal priority whereas SwitchToThread makes no such claim (for some definition of 'ready to run'). I'm also confused about the specification of "equal priority": my assumption is that this means that threads may be affected by the dynamic priority boost asssigned when returning from wait functions?

I know that I've found the public documentation to be scattered and seemingly inconsistent. I prefer not to use these functions anyway, but a clarification or pointer would be greatly appreciated now that you've reminded me of reading about them :-)

re: Why does Win32 even have Fibers?

Twiddle — Fri, 07 Jan 2005 15:38:00 GMT

>> It's somewhere between 10 and 15 milliseconds, depending on the platform. <<

I'm not sure I understand this. That would imply, assuming a hundred threads, that a thread runs for 15 milliseconds and then sleeps for nearly a second. This doesn't seem right and certainly wouldn't make for great application responsiveness. I must be missing something. Any chance of a clarification? Thanks.

re: Why does Win32 even have Fibers?

Larry Osterman — Fri, 07 Jan 2005 16:14:00 GMT

Twiddle: Yup, that's just about right. You're making a HUGE assumption though: That all 100 threads are runnable.

To verify this, simply write an application that creates 100 threads that each do some CPU bound operation (like counting). You'll find that each thread only gets to run about once a second or so. You'll also find that the system responsiveness is pretty mediochre.

The key thing to keep in mind is that on most systems, 99% of the threads on the system are not runnable.

re: Why does Win32 even have Fibers?

Twiddle — Fri, 07 Jan 2005 18:17:00 GMT

Ahha, that makes sense. Thanks for the clarification. With this in mind, it is probably not a good idea to create more than a few CPU intensive threads. This also means that, in certain circumstances, the minimum Sleep() could be a lot longer than the usually cited 10-15ms.

re: Why does Win32 even have Fibers?

Norman Diamond — Sat, 08 Jan 2005 04:01:00 GMT

1/6/2005 5:08 PM Larry Osterman

> Norman, actually it IS instruction count -
> if there are other runnable tasks on the
> system, they'll be executing instructions.

The instruction count spent servicing a page fault is instruction count that is unavailable for serving other useful tasks. The elapsed time waiting for the disk to deliver is elapsed time (with a completely different instruction count, sure but so what) where the CPU sure does serve other useful tasks.

> I stand by my claim that context switches
> are less expensive than page faults

Of course. Who said otherwise? It's just the overall estimates that we're guessing at. You heard a rumour that context switches take somewhere around 5000 instructions on average (where the CPU cannot serve other useful tasks), and yes page faults take more. I heard a rumour that page faults take around 5000 instructions on average (where the CPU cannot serve other useful tasks), and yes simpler kinds of context switches take less. We're both guessing, and there is nothing wrong with labelling guesses as guesses. I only commented because the rumours we heard differ by maybe an order of magnitude.

re: Why does Win32 even have Fibers?

Michael Grier [MSFT] — Mon, 10 Jan 2005 06:03:00 GMT

On server (e.g. compute-bound) applications, those 5000 instructions matter a whole lot. We're talking about workloads where people have considered writing unified filesystem-through-controller stacks to avoid the CPU penalty of dispatching through the layers of the filesystem to the partitioning layer to the class driver to the port driver.

For a typical interactive workload, you're right, this would be lost in the noise.

re: Why does Win32 even have Fibers?

Norman Diamond — Tue, 11 Jan 2005 00:43:00 GMT

1/9/2005 10:03 PM Michael Grier [MSFT]

> For a typical interactive workload, you're
> right, this would be lost in the noise.

I'm not sure who you're replying to here, but that's a very interesting choice of words. One typical interactive workload includes audio, and on NT-based kernels the audio sometimes gets lost in the noise. I have the impression that one reason is that the Windows 95 and 98 kernels did priority inversions properly while Windows NT4, 2000, and XP give random boosts in priority to random tasks for random short periods of time. There isn't much that the maker of Windows 95 and 98 can teach to the maker of Windows NT-based systems, but priority inversion is one of the two examples I've seen in recent years. An MSDN article explained it if you haven't seen it elsewhere.

Anyway, when 5000 instructions suddenly get used for serving a page fault for a non-interactive task, if an interactive task was playing audio then the ears hear the noise immediately.

re: Why does Win32 even have Fibers?

Larry Osterman — Tue, 11 Jan 2005 00:45:00 GMT

Norman,
That's a different (unrelated) problem. You're describing audio glitching (and video glitching).

There are LOTS of causes of audio/video glitching, ranging from overstressed systems to buggy drivers.

re: Why does Win32 even have Fibers?

Andrei Maksimenka — Fri, 14 Jan 2005 22:57:00 GMT

To John Vert:

> Another BIG reason context switches are bad is because they are serialized. So even if you have a 32-CPU machine only one CPU can be context-switching at a time. The more context switches your app does the worse it scales. Fiber switches do not acquire any locks, therefore they will scale much better.

I don't think it's correct nowadays, otherwise NT kernel wouldn't scale on multiproc machines. IIRC each processor (not sure if logical processors fit here) has its own queue of the ready for execution threads, which are scheduled with O(1) complexity. The Linux kernel, for example, previously chose threads to execute by simple enumeration, now they moved toward the same O(1) scheduler.

re: Why does Win32 even have Fibers?

Andrei Maksimenka — Fri, 14 Jan 2005 23:04:00 GMT

Larry,

when thread context switch happens, all thread context state is switched, including floting point registers state, however when fiber switch happens, only part of the real thread context state is swicthed, that's another reason why fibers switch is more lightweight than one of the "physical" thread.

Another important comment is about the perf benefits of using fibers. AFAIK SQL Server gets a lot of performance boost in *certain* scenarios, and recently NT kernel was updated to reduce the difference between thread and fiber scheduling, now it's about 20% (not sure about the number).

The most important reason not to use fibers in your application is simple - bugs. They are everywhere, there is tons of them fixed already in MSVCRT, and who knows how many of them are still there? For example, in fiber mode code needs to use Fiber Local Storage, however a in a lot of places code tries to still use Thread Local Storage, which is absolutely not the same as you surely understand.

re: Why does Win32 even have Fibers?

Andrei Maksimenka — Fri, 14 Jan 2005 23:17:00 GMT

To Twiddle:
> Ahha, that makes sense. Thanks for the clarification. With this in mind, it is probably not a good idea to create more than a few CPU intensive threads. This also means that, in certain circumstances, the minimum Sleep() could be a lot longer than the usually cited 10-15ms.

Inside the kernel, the time slice specified in Sleep() is rounder modulo quantum, the only exception is 0, which means that thread is becomes ready for the execution immediately.

Concurrency, Part 8 - Concurrency for scalability

Larry Osterman's WebLog — Tue, 01 Mar 2005 04:11:00 GMT

Larry Osterman s WebLog Why does Win32 even have Fibers | Paid Surveys

Larry Osterman s WebLog Why does Win32 even have Fibers | Paid Surveys — Sat, 30 May 2009 14:00:54 GMT

PingBack from http://paidsurveyshub.info/story.php?title=larry-osterman-s-weblog-why-does-win32-even-have-fibers

Larry Osterman s WebLog Why does Win32 even have Fibers | pool toys

Larry Osterman s WebLog Why does Win32 even have Fibers | pool toys — Thu, 18 Jun 2009 11:55:44 GMT

PingBack from http://pooltoysite.info/story.php?id=2465