Speeding up wineserver synchronization objects with shared memory

[Alexandre Julliard]

Gavriel State <gav at transgaming.com> writes:

> Even without that approach though, I don't think that the new failure mode
> is really likely to be that big a deal.  If process A owns a mutex that process
> B wants, they quite likely have some functional interdependance which would be
> disrupted as much by any generic hang in process A as by a hang followed by 
> a failure to release the mutex.

Imagine a process that does a SuspendThread() on one of its threads,
but makes sure by some kind of internal protocol that the thread is
never holding the mutex when it is suspended. This would work just
fine under Windows or under the wineserver, but would fail with the
shared memory approach.

There is simply no point in implementing a mutex that works only 99%
of the time, no matter how fast it is. The synchronization objects
have to be 100% reliable, performance only comes next; and none of the
shared memory approaches I've seen so far are 100% reliable.

In fact the original implementation of the kernel objects was based on
shared memory and signals. A lot of time was spent trying to make this
work right, but it was simply not possible without assuming that all
processes will always follow the protocol correctly, which is clearly
not something we can assume when running arbitrary Windows code.

-- 
Alexandre Julliard
julliard at winehq.com