"Robert O'Callahan" <[EMAIL PROTECTED]> writes:
> Of course it has to be 100% reliable, but since you're dealing with
> failing processes it's not 100% clear what 100% reliability is. Anyway, I
> think 100% reliability is possible for any plausible definition.
For a mutex the basic definition is obviously that you can never have
two threads holding the mutex at the same time, and that when it is
released some other thread has a chance at grabbing it. This has to be
true no matter what the process does, including corrupting memory or
crashing. You also need to make sure nothing a process does should be
able to crash/hang the wineserver or another process (except if they
fight over the same mutex of course), and then there is the small
matter of respecting the Win32 semantics...
Actually it is the last constraint that is the main problem. You can
certainly provide some kind of mutexes using shared memory; but we
don't need just 'some kind', we need Win32 mutexes. This means a mutex
is identified by a handle that can be manipulated by CloseHandle or
DuplicateHandle; it means you need to detect and handle abandoned
mutexes; it means you must support WaitForMultipleObjects, including
the 'all' case where you cannot grab the mutex unless all objects are
signaled; all things that I didn't see in your implementation ;-)
--
Alexandre Julliard
[EMAIL PROTECTED]
