Speeding up wineserver synchronization objects with shared memory

[Gavriel State]

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

Rather than have a dedicated thread to maintain any such communication 
back and forth with the server, why not simply use a signal to the first 
thread in the process.  The signal should execute regardless of whether or not
the thread is hung, and if the mutex is 'owned' by the process, but not currently 
'held', the signal handler releases the mutex, and marks it as no longer owned.

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.  And besides, once the user kills the hung 
process, the server should be able to reclaim the shared mutex object anyway.

-Gav

-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav at transgaming.com