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.
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. This memory block holds the lock associated with each mutex, and the wineserver itself does the actions that I previously ascribed to the client thread. (It's a bit tricky because the wineserver never wants to block on acquiring the lock in shared memory; you have to set some flag in the lock word, wait for the client process to send you a message that it's released its mutex lock, and then try again.) As long as the wineserver maintains its own record of who owns each mutex, it need not actually trust any of the contents of the shared memory blocks. Other than not requiring separate client threads, this design also requires fewer process context switches. In the non-contended case, acquiring a mutex previously held by another process would require only a switch to the wineserver and back.
Sorry I'm not familiar with the Wine code and I don't have time to dig into it, but I just want to urge you not to give up on finding a safe, very efficient solution.
Rob