Optimizing synchronization objects

[Alexandre Julliard]

Daniel Santos <daniel.santos at pobox.com> writes:

> As you can see this can get more complicated. If the server discovers
> that an server object isn't signaled it will have to notify the client
> to rollback the locks and wait for server objects to be ready.
>
> So which of these solution is most appealing to you?

None of them, really.

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.

SysV synchronization objects are broken in various ways and should be
avoided.

I think the most promising approach would be to add a process-local
cache for objects that don't need inter-process synchronization. As soon
as the object needs complex work that involves the server or another
process (DuplicateHandle, WaitForMultipleObjects, named objects, etc.)
it graduates to a full server object, and from then on goes through the
normal path. This should cover the most performance-critical cases.

-- 
Alexandre Julliard
julliard at winehq.org