Optimizing synchronization objects

[Daniel Santos]

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

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.

Thanks,
Daniel