Gavriel State gav@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...