[ros-kernel] Commits to subsys/win32k
thomas at reactsoft.com
Fri Jul 9 12:24:59 CEST 2004
Mike Nordell wrote:
> Have you considered how this will affect SMP systems?
It won't affect SMP systems any different than the current
implementation AFAIK. The only difference is that there are going to be
thousands of locks less. I tested how often the user handle table is
locked with our current implementation, anyhow 1000 locks for a single
mouse move. And that doesn't include all the locks (e.g. locks to
relative windows etc.).
> OK, maybe this global (per-winsta is in effect global, from a users POV)
> lock for user, but I'm confident something similar will not be
> when it comes to GDI.
I agree with you. That's why I'm not going to touch GDI at all. But our
GDI for sure needs some optimization.
> I'd appreciate some elaboration on the considerations taken that led
> to the
> conclusion this was the way to go.
See reasons above. Massive lockings all over the place and usage of
handles in internal code.
> At first glance it seems this approach,
> paired with the unock/callback/lock idiom can create a few problems -
> if a thread on CPU0 is doing unluck(butterfingers, but I left it
> since it became quite appropriate) in preparation to do a callback,
> but then
> CPU1 gets the global lock and e.g. closes the window?
I already considered this case. Therefore the object is referenced
before releasing the lock. When it gets destroyed it's still in memory
so we don't get into trouble when returning from the callback. After the
callback the lock is acquired again and it is checked if the window
and/or thread was destroyed. If so, further code needs special handling
of course. But that's not solved well in our current implementation as
More information about the Ros-kernel