Optimizing synchronization objects

[Michael Stefaniuc]

On 09/17/2015 09:36 AM, Daniel Santos wrote:
> On 09/16/2015 10:49 AM, Vincent Povirk wrote:
>> Well, I didn't read what he said that way:
>>
>> On Mon, Sep 14, 2015 at 2:18 AM, Alexandre Julliard
>> <julliard at winehq.org> wrote:
>>> Using shared memory means you'll need one page per object, because you
>>> can't allow a process to corrupt the state of unrelated objects. This
>>> doesn't scale.
>> This is true only if you share memory between multiple clients. If you
>> share memory only between wineserver and individual clients, you need
>> at least one page per client, but you can use the entire page (and
>> most of the overhead can remain in the individual processes, ideally
>> you only need 32 or 64 bits of shared memory per object).
>>
>> Maybe there's another objection to this approach, but I didn't see it
>> in this thread.
>>
> Actually, this does not need to be true if you share memory between
> multiple clients. Every unique combination of processes involved in
> sharing objects can have it's own "process group" where those objects,
> and only those objects reside. Further, to identify corruption, each
> process can keep accounting on its interaction with each object which
> can be used to validate that the memory has not been altered outside of
> proper use of the API. For a semaphore, I think that 32 bits will be
> enough to and leave plenty of room left over for various flags, like one
> for "object being moved" and another for "server wants a notification."
Did you look at memfd as opposed to plain share memory and how that can
simplify your memory corruption problem?
I know that Michael Müller worked on that and proof of concept code is
available, see
https://github.com/wine-compholio/wine-staging/tree/master/patches/server-Shared_Memory

> 
> If an additional process gains access to the object it can just be moved
> again to the new process group. This design would allow complex waits to
> occur on the server without requiring the object to be migrated. Of
> course the server would never block, it will rely upon the client to
> signal it in some form when a "signaling" function is performed
> (ReleaseMutex, ReleaseSemaphore, WakeConditionVariable, etc.).
> 
> What are your thoughts Alexandre? If I implement it and provide tests to
> reasonably prove that memory corruption cannot affect the wineserver's
> function, nor the stability of other programs that are not sharing
> objects will you consider it at some point? I know that something like
> this would have to sit in staging for a long time, but I just don't want
> to build something that has no chance of being merged.

bye
	michael