OSDev.org

Microsoft claims that its dispatcher in Windows 7 is now lockless but I wonder really what they mean with lockless in this case. Did this mean they had a grand lock on the dispatcher as a whole before and now they just lock individual objects?

Basically how lockless can you make the dispatcher? I've not figured out how to make it completely lockless if it is even possible. I must lock individual objects and also I have to disable the interrupts on the specific CPU during the dispatch. Is there some magic I don't know about?

Hi,

OSwhatever wrote:Microsoft claims that its dispatcher in Windows 7 is now lockless but I wonder really what they mean with lockless in this case. Did this mean they had a grand lock on the dispatcher as a whole before and now they just lock individual objects?

From here http://channel9.msdn.com/shows/Going+Deep/Arun-Kishan-Farewell-to-the-Windows-Kernel-Dispatcher-Lock/:

"In order to promote further scalability of the NT kernel, Arun completely eliminated the dispatcher lock and replaced it with a much finer grained set of synchronization primitives."

The words "much finer grained set of synchronization primitives" doesn't mean lockless, and could just mean 2 spinlocks rather than one.

Um, I'd be tempted to assume the video on that page contains something that might be relevant. I haven't watched it yet.

[EDIT] So, I watched most of the video, and they've basically shifted from "huge over-complicated mess with one dispatcher spinlock" to "huge over-complicated mess with one spinlock per object". [/EDIT]


Cheers,

Brendan

Brendan wrote:[EDIT] So, I watched most of the video, and they've basically shifted from "huge over-complicated mess with one dispatcher spinlock" to "huge over-complicated mess with one spinlock per object". [/EDIT]


Cheers,

Brendan

I watched it too and I must agree with the huge-overcomplicated part.

I finally got some time to watch the whole video. I found it really interesting, especially since I used a similar technique a few years ago in the design of a user-space database driver manager (for my day job, not just as a hobby).

I'm curious about the "over-complicated" comments. Do you guys think that, given the constraints of backwards compatibility with the existing NT API, his solution was too complicated? Or do you just think NT is too complicated in general? If it's the former, please provide specific criticisms and your take on how you would solve it.

Hi,

Colonel Kernel wrote:I'm curious about the "over-complicated" comments. Do you guys think that, given the constraints of backwards compatibility with the existing NT API, his solution was too complicated? Or do you just think NT is too complicated in general? If it's the former, please provide specific criticisms and your take on how you would solve it.

It's the latter. The number of different things a thread can be waiting for (and the allowed permutations of them) is excessive; and all the extra bloat bolted on the side is unnecessary.

I'd assume that half the reason for "over-complicated" is backward compatibility, and the other half is that it's a monolithic design (e.g. where device drivers may need to run in the context of currently blocked threads).


Cheers,

Brendan