"Robert O'Callahan" roc+@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