Speeding up wineserver synchronization objects with shared memory

[Robert O'Callahan]

Ove Kaaven wrote:
> 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...

I call that "not a new failure mode" because it's the same behavior as if
the faulty client process had a bug that caused it to fail to release the
mutex in the first place. If you want a more restricted fault model, you
can limit the vulnerability window by having the client periodically poll
for owned-but-unlocked mutexes and release them to the wineserver.

> > 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.

You can do it all with non-blocking operations. The shared memory solution
previously proposed had the disastrous property that a misbehaving client
process could interfere with mutexes owned by other processes. It doesn't
have to be that way if you use a separate shared memory block per client.

This could be extended to other shared resources too. But I could believe
that it is too complicated to be worth doing.

Rob
-- 
[Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student
"Now when Joshua was near Jericho, he looked up and saw a man standing in
front of him with a drawn sword in his hand. Joshua went up to him and
asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but
as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]