Speeding up wineserver synchronization objects with shared memory

[Ove Kaaven]

On Sat, 24 Feb 2001, Robert O'Callahan wrote:

> Ove Kaaven wrote:
> > On Thu, 22 Feb 2001, Robert O'Callahan wrote:
> > > Then on some other thread in the same address space
> > > that serves wineserver requests:
> > 
> > There's no such thread, and will never be such a thread (having the
> > wineserver calling into client threads is an inherently unstable
> > design).
> 
> The wineserver need not depend on the client thread responding to its
> (asynchronous) messages. In this case, if the client ignores the
> messages,  you get the same effect as if it never releases its mutex,
> which is not a new failure mode.

Sure it is, if the process isn't holding the mutex. Your design lets a
process own the mutex without holding it. So if a process acquires it,
then releases it, does something else for 10 minutes and then hangs, and
some other process decides it should grab the mutex, then it should be
allowed to do so, since the original process isn't holding it. But it
can't...

> Actually there is another design that doesn't need a per-client thread.
> Instead it uses a per-client memory block shared between the client and
> the wineserver.

Alexandre already shot down the shared-memory solution, especially
disliking solutions that force the wineserver out of its single-threaded
model, like making it do locking and atomic operations for itself.