Lockless dispatcher

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
OSwhatever
Member
Member
Posts: 595
Joined: Mon Jul 05, 2010 4:15 pm

Lockless dispatcher

Post by OSwhatever »

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?
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Lockless dispatcher

Post by Brendan »

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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
OSwhatever
Member
Member
Posts: 595
Joined: Mon Jul 05, 2010 4:15 pm

Re: Lockless dispatcher

Post by OSwhatever »

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.
User avatar
Colonel Kernel
Member
Member
Posts: 1437
Joined: Tue Oct 17, 2006 6:06 pm
Location: Vancouver, BC, Canada
Contact:

Re: Lockless dispatcher

Post by Colonel Kernel »

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.
Top three reasons why my OS project died:
  1. Too much overtime at work
  2. Got married
  3. My brain got stuck in an infinite loop while trying to design the memory manager
Don't let this happen to you!
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Lockless dispatcher

Post by Brendan »

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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Post Reply