Speeding up wineserver syncronization objects with shared memory

Alexandre Julliard julliard at winehq.com
Thu Feb 15 17:20:23 CST 2001


Gavriel State <gav at transgaming.com> writes:

> Definitely a drawback, I agree.  But the shared memory area could be relatively
> high in the address space, so that a stray pointer is much more likely to run 
> into unmapped memory and segfault before overwriting crucial data. 

This is only one failure case, but there are many others; for instance
stack corruption that causes the app to jump somewhere inside
ReleaseMutex, which will then happily modify the right address in the
wrong way.

> The only way we're going to be able to get both speed and safety though is
> to have some kernel support.  While that's beyond the scope of what I'd like
> to accomplish in the short term, I think that it's something worth thinking
> about more.  While the solution proposed by David Howells may be overkill, I'm 
> not sure that simply changing the communication mechanism as you suggested
> (http://www.winehq.com/News/2000-37.html#0) will speed things up enough - 
> we'll still have the context switch overhead.

The main problem is the TLB flush due to switching address spaces; but
I don't see any way to avoid this if we want memory protection (which
we definitely do). The only way to know if we can make it fast enough
is to implement it and benchmark it...

> At least in the case of mutexes, I believe that all we need to do is
> make sure that the count field is always modified through interlocked
> increment/decrement/etc including the wineserver.

I think you underestimate the complexity of getting this right. For
instance, how do you determine the address of the count field from the
mutex handle, keeping in mind that handles can be manipulated from
other threads or even other processes (cf. DuplicateHandle)?  How do
you cope with a thread dying in the middle of an operation?

Of course you can ignore all these special cases, and it will even
work most of the time. But it's clearly not a viable general
solution...

-- 
Alexandre Julliard
julliard at winehq.com



More information about the wine-devel mailing list