Speeding up wineserver synchronization objects with shared memory

[Alexandre Julliard]

"Robert O'Callahan" <roc+ at cs.cmu.edu> writes:

> So your concern is simply that if it's too simple to lock the mutex, then
> you have an unacceptably high probability of a runaway process
> accidentally locking the mutex, whereas you regard the probability of the
> process accidentally calling AcquireMutex again (or executing the
> protected control transfer on its own) as acceptably low. That seems
> reasonable.

No, that's not my concern. The probability of error doesn't matter at
all, I don't mind if the process locks the mutex by accident. What
must not be able to happen is that the process somehow corrupts the
state as seen from the wineserver or other processes. That is, it
doesn't matter if the process thinks it got the mutex when it didn't;
but it must not be possible to make the wineserver see two processes
holding the mutex, or some other inconsistent state. Any inconsistency
must remain local to the process.

> Yeah, but that doesn't seem fundamental --- the wineserver can always take
> ownership of the mutex itself when it needs to do a complex atomic
> operation. I'll let Gavriel work out the details :-).

My point is that getting the details right is what is important; and
if you are not interested in doing this, then there is no point in
arguing any further.

-- 
Alexandre Julliard
julliard at winehq.com